5.7.4. セキュリティー
Audit の実行可能な監視機能がシンボリックリンクで機能しない
-w
オプションによって提供されるファイルモニターリングでは、パスを直接追跡できません。デバイスと inode へのパスを解決して、実行したプログラムとの比較を行う必要があります。実行可能なシンボリックリンクを監視する監視機能は、メモリーで実行されるプログラムではなく、デバイスとシンボリックリンク自体の inode を監視します。これは、シンボリックリンクの解決から確認できます。監視機能がシンボリックリンクを解決して作成される実行プログラムを取得する場合でも、ルールは別のシンボリックリンクから呼び出されるマルチコールバイナリーでトリガーされます。これにより、誤検出でログがいっぱいになります。したがって、Audit の実行可能な監視機能は、シンボリックリンクでは機能しません。
この問題を回避するには、プログラム実行可能ファイルの解決されたパスに対して監視を設定し、comm=
や proctitle=
フィールドに記載されている最後のコンポーネントを使用して、生成されるログメッセージをフィルターします。
(BZ#1846345)
/etc/selinux/config
の SELINUX=disabled
が正常に動作しません。
/etc/selinux/config
で SELINUX=disabled
オプションを使用して SELinux を無効にすると、カーネルが SELinux を有効にして起動し、その後のブートプロセスで無効化モードに切り替わります。これにより、メモリーリークが生じる可能性があります。
この問題を回避するには、SELinux を完全に無効にする必要がある場合に SELinux の使用 の システムの起動時に SELinux モードの変更 で説明されているように、selinux=0
パラメーターをカーネルコマンドラインに追加して SELinux を無効にすることが推奨されます。
(JIRA:RHELPLAN-34199)
libselinux-python
は、そのモジュールからのみ利用可能
libselinux-python
パッケージには、SELinux アプリケーション開発用の Python 2 バインディングのみが含まれ、後方互換性に使用されます。このため、libselinux-python
コマンドを使用して、デフォルトの RHEL 8 リポジトリーで dnf install libselinux-python
コマンドが利用できなくなりました。
この問題を回避するには、libselinux-python
モジュールおよび python27
モジュールの両方を有効にし、以下のコマンドで libselinux-python
パッケージとその依存関係をインストールします。
# dnf module enable libselinux-python # dnf install libselinux-python
または、1 つのコマンドでインストールプロファイルを使用して libselinux-python
をインストールします。
# dnf module install libselinux-python:2.8/common
これにより、各モジュールを使用して libselinux-python
をインストールできます。
(BZ#1666328)
udica
は、--env container=podman
で開始したときにのみ UBI 8 コンテナーを処理します。
Red Hat Universal Base Image 8 (UBI 8) コンテナーは、podman
の値ではなく、コンテナー
環境変数を oci
値に設定します。これにより、udica
ツールがコンテナー JavaScript Object Notation (JSON) ファイルを分析しなくなります。
この問題を回避するには、--env container=podman
パラメーターを指定して、podman
コマンドで UBI 8 コンテナーを起動します。そのため、udica
は、上記の回避策を使用している場合に限り、UBI 8 コンテナーの SELinux ポリシーを生成することができます。
rpm-plugin-selinux
パッケージを削除すると、システムからすべての selinux-policy
パッケージが削除されます。
rpm-plugin-selinux
パッケージを削除すると、マシン上で SELinux が無効になります。また、システムからすべての selinux-policy
パッケージも削除されます。rpm-plugin-selinux
パッケージを繰り返しインストールしてから、selinux-policy-targeted
ポリシーが以前に存在していても、selinux-policy-minimum
SELinux ポリシーをインストールします。ただし、繰り返しインストールしても、ポリシーの変更のために SELinux 設定ファイルが更新されることはありません。このため、rpm-plugin-selinux
パッケージを再インストールしても、SELinux が無効になります。
この問題を回避するには、以下を実行します。
-
umount /sys/fs/selinux/
コマンドを実行します。 -
足りない
selinux-policy-targeted
パッケージを手動でインストールします。 -
ポリシーが
SELINUX=enforcing
と同等になるように/etc/selinux/config
ファイルを編集します。 -
コマンド
load_policy -i
を実行します。
これにより、SELinux が有効になり、以前と同じポリシーが実行されている状態になります。
(BZ#1641631)
SELinux により、systemd-journal-gatewayd corosync
が、corosync
によって作成される共有メモリーファイル上で newfstatat()
を呼び出さなくなります。
SELinux ポリシーには、systemd-journal-gatewayd
が corosync
サービスによって作成されるファイルにアクセスできるルールが含まれません。その結果、SELinux は、systemd-journal-gatewayd
による、corosync
で作成された共有メモリーファイルの newfstatat()
関数を呼び出しを拒否します。
この問題を回避するには、このシナリオを実現する許可ルールでローカルポリシーモジュールを作成します。SELinux ポリシーの allow
および dontaudit ルールの生成の詳細は、man ページの audit2allow(1) を参照してください。以前の回避策により、systemd-journal-gatewayd
は、Enforcing モードで SELinux により corosync
で作成した共有メモリーファイルの関数を呼び出すことができます。
(BZ#1746398)
SELinux が原因で auditd
によるシステムの停止や電源オフができません。
SELinux ポリシーには、Audit デーモンが power_unit_file_t
systemd
ユニットを起動できるようにするルールがありません。したがって、Logging ディスクパーティションに領域が残っていない場合など、auditd
がシステムを停止したり、電源をオフにしたりできるように設定した場合でも、システムの停止や電源オフができません。
この問題を回避するには、カスタムの SELinux ポリシーモジュールを作成します。こうすることで、auditd
は回避策を適用している場合に限り、システムを正常に停止したり、電源をオフにしたりできます。
ユーザーは、ロックされたユーザーとして sudo
コマンドを実行できます。
ALL
キーワードで sudoers
パーミッションが定義されているシステムでは、パーミッションを持つ sudo
ユーザーは、アカウントがロックされているユーザーとして sudo
コマンドを実行できます。そのため、ロックされたアカウントと期限切れのアカウントを使用して、コマンドを実行し続けることができます。
この問題を回避するには、/etc/shells
内の有効なシェルの適切な設定と併せて、新たに実装した runas_check_shell
オプションを有効にします。これにより、攻撃者が bin
などのシステムアカウントでコマンドを実行するのを防ぎます。
(BZ#1786990)
デフォルトのロギング設定がパフォーマンスに与える悪影響
デフォルトのログ環境設定は、メモリーを 4 GB 以上使用する可能性があり、rsyslog
で systemd-journald
を実行している場合は、速度制限値の調整が複雑になります。
詳細は、ナレッジベースの記事 Negative effects of the RHEL default logging setup on performance and their mitigations を参照してください。
(JIRA:RHELPLAN-10431)
config.enabled
による rsyslog
出力の Parameter not known
エラー。
rsyslog
の出力では、config.enabled
ディレクティブを使用すると、設定処理エラーで予期しないバグが発生します。これにより、include()
ステートメントを除き、config.enabled
ディレクティブを使用すると、parameter not known
エラーが表示されます。
この問題を回避するには、config.enabled=on
を設定するか、include()
ステートメントを使用します。
(BZ#1659383)
特定の rsyslog
優先度の文字列が正常に動作しません。
imtcp
に GnuTLS 優先度文字列を設定して、完成していない暗号化をきめ細かく制御できるようになりました。したがって、rsyslog
では、以下の優先文字列が正常に動作しません。
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+DHE-RSA:+AES-256-GCM:+SIGN-RSA-SHA384:+COMP-ALL:+GROUP-ALL
この問題を回避するには、正しく機能する優先度文字列のみを使用します。
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+ECDHE-RSA:+AES-128-CBC:+SIGN-RSA-SHA1:+COMP-ALL:+GROUP-ALL
したがって、現在の設定は、正しく機能する文字列に限定する必要があります。
SHA-1 署名を使用するサーバーへの接続が GnuTLS で動作しません。
証明書の SHA-1 署名は、GuTLS セキュアな通信ライブラリーにより、セキュアでないものとして拒否されます。したがって、TLS のバックエンドとして GnuTLS を使用するアプリケーションは、このような証明書を提供するピアへの TLS 接続を確立することができません。この動作は、その他のシステム暗号化ライブラリーと一貫性がありません。この問題を回避するには、サーバーをアップグレードして、SHA-256 または強力なハッシュを使用して署名した証明書を使用するか、LEGACY ポリシーに切り替えます。
(BZ#1628553)
TLS 1.3 は、FIPS モードの NSS で動作しません。
TLS 1.3 は、FIPS モードで動作しているシステムでは対応していません。その結果、相互運用性に TLS 1.3 を必要とする接続が、FIPS モードで動作しているシステムで機能しません。
その接続を有効にするには、システムの FIPS モードを無効にするか、ピアで TLS 1.2 のサポートを有効にします。
OpenSSL
が、生の RSA または RSA-PSS の署名に対応していない PKCS #11 トークンを誤って処理します。
OpenSSL
ライブラリーは、PKCS #11 トークンの鍵関連の機能を検出しません。したがって、生の RSA または RSA-PSS の署名に対応しないトークンで署名が作成されると、TLS 接続の確立に失敗します。
この問題を回避するには、/etc/pki/tls/openssl.cnf
ファイルの crypto_policy
セクションの末尾にある .include
行の後に、以下の行を追加します。
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
これにより、このシナリオで TLS 接続を確立できます。
OpenSSL が、TLS 1.3 の CertificateRequest
メッセージに、不正な status_request
拡張を生成します。
OpenSSL サーバーは、status_request
拡張とクライアント証明書ベースの認証サポートが有効な場合に、CertificateRequest
メッセージに正しくない status_request
拡張を送信します。この場合、OpenSSL は RFC 8446
プロトコルに準拠する実装と同時には動作しません。その結果、CertificateRequest
メッセージの拡張を適切に検証するクライアントは OpenSSL サーバーとの接続を中止します。この問題を回避するには、接続のいずれかで TLS 1.3 プロトコルのサポートを無効にするか、OpenSSL サーバーの status_request
のサポートを無効にします。これにより、サーバーが不正なメッセージを送信しなくなります。
ssh-keyscan
が、FIPS モードでサーバーの RSA 鍵を取得できません。
FIPS モードで RSA 署名の SHA-1
アルゴリズムが無効になっています。これにより、ssh-keyscan
ユーティリティーがそのモードで稼働しているサーバーの RSA 鍵を取得できなくなります。
この問題を回避するには、代わりに ECDSA 鍵を使用するか、サーバーの /etc/ssh/ssh_host_rsa_key.pub
ファイルから鍵をローカルに取得します。
Libreswan
が、すべての設定において seccomp=enabled
で正常に動作しません。
Libreswan
SECCOMP サポート実装で許可された syscall のセットは現在、完全ではありません。したがって、SECCOMP が ipsec.conf
ファイルで有効となっている場合、syscall のフィルターリングは、pluto
デーモンの正常な機能に必要な syscall まで拒否します。つまり、デーモンは強制終了され、ipsec
サービスが再起動されます。
この問題を回避するには、seccomp=
オプションを設定して、disabled
状態に戻します。SECCOMP サポートは、ipsec
を正常に実行するため、無効のままにしておく必要があります。
SSG における相互依存ルールの特定のセットが失敗する可能性があります。
ルールとその依存関係の順序付けを定義しないため、ベンチマークの SCAP Security Guide
(SSG) ルールの修正が失敗する可能性があります。たとえば、特定の順番で複数のルールを実行する必要がある場合、あるルールがコンポーネントをインストールし、別のルールが同じコンポーネントを設定した場合すると、それらは正しくない順序で実行される可能性があり、修正によってエラーが報告されます。この問題を回避するには、修正を回実行して、番目の実行で依存ルールを修正します。
SCAP Workbench が、カスタムプロファイルから結果ベースの修正を生成できません。
SCAP Workbench ツールを使用してカスタムプロファイルから結果ベースの修正ロールを生成しようとすると、次のエラーが発生します。
Error generating remediation role .../remediation.sh: Exit code of oscap was 1: [output truncated]
この問題を回避するには、oscap
コマンドを、--tailoring-file
オプションとともに使用します。
(BZ#1640715)
RHEL 8 のキックスタートが、com_redhat_oscap
の代わりに org_fedora_oscap
を使用
キックスタートは、com_redhat_oscap
ではなく、org_fedora_oscap
として Open Security Content Automation Protocol (OSCAP) Anaconda アドオンを参照します。これが、混乱を招く可能性があります。これは、Red Hat Enterprise Linux 7 との後方互換性を維持するために行われます。
(BZ#1665082)
OSCAP Anaconda Addon
がすべてのパッケージをテキストモードでインストールしません。
OSCAP Anaconda Addon
プラグインは、インストールがテキストモードで実行している場合、システムインストーラーによってインストールに選択されているパッケージの一覧を変更することはできません。これにより、キックスタートを使用してセキュリティーポリシープロファイルが指定され、インストールがテキストモードで実行している場合に、インストール中にセキュリティーポリシーに必要な追加パッケージがインストールされません。
この問題を回避するには、グラフィカルモードでインストールを実行するか、キックスタートファイルの %packages
セクションにあるセキュリティーポリシーで、セキュリティーポリシープロファイルに必要なパッケージをすべて指定します。
これにより、セキュリティーポリシープロファイルで必要となるパッケージは、上記の回避策のいずれかを行わなければ RHEL インストールインストール時にインストールされません。また、インストール後のシステムは、指定のセキュリティーポリシープロファイルと互換性がありません。
oscap Anaconda Addon
がカスタムプロファイルを正しく処理しません。
OSCAP Anaconda Addon
プラグインは、個別のファイルでカスタマイズを使用したセキュリティープロファイルを適切に処理しません。これにより、対応する Kickstart セクションで適切に指定しても、RHEL グラフィカルインストールでカスタマイズしたプロファイルは利用できません。
この問題を回避するには、ナレッジベースの記事 Creating a single SCAP data stream from an original DS and a tailoring file を参照してください。この回避策により、RHEL グラフィカルインストールでカスタマイズした SCAP プロファイルを使用できます。
(BZ#1691305)
GnuTLS が NSS サーバーとの現行セッションを再開できません。
TLS (Transport Layer Security) 1.3 セッションを再開するとき、GnuTLS
クライアントは 60 ミリ秒に加えて、サーバーがセッション再開データを送信するために推定されるラウンドトリップタイムの分だけ待機します。サーバーがこの時間内に再開データを送信しないと、クライアントは現行セッションを再開せずに新しいセッションを作成します。これは、通常のセッションネゴシエーションのパフォーマンスに若干影響することを除いて、深刻な悪影響を与えることはありません。
リモートシステムを --sudo でスキャンすると、oscap-ssh ユーティリティーが失敗します。
oscap-ssh
ツールで --sudo
オプションを使用してリモートシステムの Security Content Automation Protocol (SCAP) スキャンを実行すると、リモートシステムの oscap
ツールが、root
ユーザーとして、スキャン結果ファイルとレポートファイルを一時ディレクトリーに保存します。リモートマシンの umask
設定を変更した場合は、oscap-ssh
がこれらのファイルにアクセスできない可能性があります。この問題を回避するには、ソリューション "oscap-ssh --sudo" fails to retrieve the result files with "scp: …: Permission denied" error で説明されているように、oscap-ssh
ツールを変更します。これにより、oscap
はターゲットユーザーとしてファイルを保存し、oscap-ssh
は普通にファイルにアクセスします。
OpenSCAP が、YAML マルチライン文字列から空の行を削除することにより、誤検出が生成されます。
OpenSCAP がデータストリームから Ansible 修正を生成すると、YAML マルチライン文字列から空の行が削除されます。一部の Ansible 修正にはリテラル設定のファイルコンテンツが含まれているため、空の行を削除すると、対応する修正に影響します。空の行に何の効果もないとしても、これにより openscap
ユーティリティーが、対応する Open Vulnerability and Assessment Language (OVAL) チェックに失敗します。この問題を回避するには、ルールの説明を確認し、空の行がないために失敗したスキャン結果をスキップします。または、Bash の修正ではこれらの誤検出が発生しないので、Ansible の修正の代わりに Bash の修正を使用します。
OSPP ベースのプロファイルに、GUI パッケージグループとの互換性がありません。
Server with GUI パッケージグループでインストールされる GNOME
パッケージには、Operating System Protection Profile (OSPP) に準拠しない nfs-utils
パッケージが必要です。これにより、OSPP または OSPP ベースのプロファイル (Security Technical Implementation Guide (STIG) など) を使用したシステムのインストール時にServer with GUIパッケージグループを選択すると、インストールが中断されます。OSPP ベースのプロファイルがインストール後に適用される場合、システムは起動できません。この問題を回避するには、Server with GUIパッケージグループや、または OSPP プロファイルと OSPP ベースのプロファイルを使用する際に GUI をインストールするその他のグループをインストールしないでください。代わりにServerまたはMinimal Installパッケージグループを使用すると、システムは問題なくインストールされ、正常に機能します。
RHEL 8 システムに Server with GUI パッケージグループが含まれる場合には e8 プロファイルを使用して修復できません。
OpenSCAP Anaconda Add-on を使用して、Verify Integrity with RPM グループからルールを選択するプロファイルが含まれる Server With GUI パッケージグループでシステムを強化すると、システム上のメモリーを過剰に必要とします。この問題は、OpenSCAP スキャナーが原因で発生します。詳細は、Scanning large numbers of files with OpenSCAP causes systems to run out of memory を参照してください。このため、RHEL8 Essential Eight (e8) プロファイルを使用してシステムを正常に強化できません。この問題を回避するには、サーバーなどの小規模なパッケージグループを選択して、インストール後に必要な追加パッケージをインストールします。その結果、システムにはパッケージ数が少なくなり、スキャンに必要なメモリーが少なくなるため、システムを自動的に強化できます。
(BZ#1816199)
OpenSCAP で多数のファイルをスキャンすると、システムがメモリーを使い切ってしまいます。
OpenSCAP スキャナーは、スキャンが完了するまで、収集したすべての結果をメモリーに保存します。そのため、たとえば、GUI および Workstation を使用する大規模なパッケージグループから、大量のファイルをスキャンする場合、RAM が少ないシステムでメモリーが不足する可能性があります。この問題を回避するには、RAM が少ないシステムで、より小さいパッケージグループ (例: Server および Minimal Install) を使用します。大規模なパッケージグループを使用する必要がある場合は、システムで仮想環境またはステージング環境に十分なメモリーがあるかどうかをテストしてください。または、スキャンプロファイルを調整して、/
ファイルシステム全体の再帰を行う、以下のルールの選択を解除することができます。
-
rpm_verify_hashes
-
rpm_verify_permissions
-
rpm_verify_ownership
-
file_permissions_unauthorized_world_writable
-
no_files_unowned_by_user
-
dir_perms_world_writable_system_owned
-
file_permissions_unauthorized_suid
-
file_permissions_unauthorized_sgid
-
file_permissions_ungroupowned
-
dir_perms_world_writable_sticky_bits
選択を外すことで、OpenSCAP スキャンで、システムがメモリー不足になるのを防ぎます。