10.4. セキュリティー
ユーザーは、ロックされたユーザーとして sudo コマンドを実行できます。
ALL キーワードで sudoers パーミッションが定義されているシステムでは、パーミッションを持つ sudo ユーザーは、アカウントがロックされているユーザーとして sudo コマンドを実行できます。そのため、ロックされたアカウントと期限切れのアカウントを使用して、コマンドを実行し続けることができます。
この問題を回避するには、/etc/shells 内の有効なシェルの適切な設定と併せて、新たに実装した runas_check_shell オプションを有効にします。これにより、攻撃者が bin などのシステムアカウントでコマンドを実行するのを防ぎます。
(BZ#1786990)
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 ポリシーを生成することができます。
デフォルトのロギング設定がパフォーマンスに与える悪影響
デフォルトのログ環境設定は、メモリーを 4 GB 以上使用する可能性があり、rsyslog で systemd-journald を実行している場合は、速度制限値の調整が複雑になります。
詳細は、ナレッジベースの記事 Negative effects of the RHEL default logging setup on performance and their mitigations を参照してください。
(JIRA:RHELPLAN-10431)
/etc/passwd- のファイル権限が CIS RHEL 8 Benchmark 1.0.0 と合致しない
CIS Benchmark の問題により、/etc/passwd- バックアップファイルの権限を保証する SCAP ルールの修正によって、権限が 0644 に設定されます。ただし、CIS Red Hat Enterprise Linux 8 Benchmark 1.0.0 では、そのファイルに対するファイルパーミッション 0600 が必要です。そのため、修正後、/etc/passwd- のファイル権限はベンチマークに合うように設定されません。
/etc/selinux/config の SELINUX=disabled が正常に動作しません。
/etc/selinux/config で SELINUX=disabled オプションを使用して SELinux を無効にすると、カーネルが SELinux を有効にして起動し、その後のブートプロセスで無効化モードに切り替わります。これにより、メモリーリークが生じる可能性があります。
この問題を回避するには、SELinux を完全に無効にする必要がある場合に SELinux の使用 の システムの起動時に SELinux モードの変更 で説明されているように、selinux=0 パラメーターをカーネルコマンドラインに追加して SELinux を無効にすることが推奨されます。
(JIRA:RHELPLAN-34199)
crypto-policies が Camellia 暗号を誤って許可する。
RHEL 8 システム全体の暗号化ポリシーでは、製品ドキュメントで説明されているように、すべてのポリシーレベルで Camellia 暗号を無効にする必要があります。ただし、Kerberos プロトコルでは、デフォルトでこの Camellia 暗号が有効になります。
この問題を回避するには、NO-CAMELLIA サブポリシーを適用します。
# update-crypto-policies --set DEFAULT:NO-CAMELLIA
これまでに上記のコマンドで、DEFAULT から切り替えたことがある場合は、DEFAULT を暗号化レベルの名前に置き換えます。
その結果、この回避策を使用して Cemellia 暗号を無効にしている場合に限り、システム全体の暗号化ポリシーを使用する全ポリシーで、この暗号化を適切に拒否できます。
SHA-1 署名を使用するサーバーへの接続が GnuTLS で動作しません。
証明書の SHA-1 署名は、GuTLS セキュアな通信ライブラリーにより、セキュアでないものとして拒否されます。したがって、TLS のバックエンドとして GnuTLS を使用するアプリケーションは、このような証明書を提供するピアへの TLS 接続を確立することができません。この動作は、その他のシステム暗号化ライブラリーと一貫性がありません。
この問題を回避するには、サーバーをアップグレードして、SHA-256 または強力なハッシュを使用して署名した証明書を使用するか、LEGACY ポリシーに切り替えます。
(BZ#1628553)
Libreswan は、leftikeport および rightikeport を無視します。
Libreswan は、host-to-host Libreswan 接続では leftikeport および rightikeport オプションを無視します。これにより、Libreswan は、leftikeport と rightikeport の設定に関係なく、デフォルトのポートを使用します。現在利用できる回避策はありません。
IKEv2 で複数のラベルが付いた IPsec 接続が正常に動作しない
Libreswan が IKEv2 プロトコルを使用する場合、IPsec のセキュリティーラベルは複数の接続では正しく機能しません。これにより、ラベルが付いた IPsec を使用する Libreswan は、最初の接続のみを確立できますが、後続の接続を確立することができません。複数の接続を使用するには、IKEv1 プロトコルを使用します。
FIPS モードの OpenSSL が、特定の D-H パラメーターのみを受け入れます。
FIPS モードでは、OpenSSL を使用する TLS クライアントは bad dh value エラーを返し、手動で生成されたパラメーターを使用するようにサーバーへの TLS 接続を中止します。これは、FIPS 140-2 に準拠するよう設定されている場合、OpenSSL が NIST SP 800-56A rev3 付録 D (RFC 3526 で定義されたグループ 14、15、16、17、18、および RFC 7919 で定義されたグループ) に準拠した Diffie-Hellman パラメーターでのみ機能するためです。また、OpenSSL を使用するサーバーは、その他のパラメーターをすべて無視し、代わりに同様のサイズの既知のパラメーターを選択します。この問題を回避するには、準拠するグループのみを使用します。
(BZ#1810911)
OpenSC pkcs15-init によるスマートカードのプロビジョニングプロセスが適切に動作しません。
file_caching オプションは、デフォルトの OpenSC 設定で有効になっているため、キャッシュ機能は pkcs15-init ツールから一部のコマンドを適切に処理しません。したがって、OpenSC を使用したスマートカードのプロビジョニングプロセスは失敗します。
この問題を回避するには、以下のスニペットを /etc/opensc.conf ファイルに追加します。
app pkcs15-init {
framework pkcs15 {
use_file_caching = false;
}
}
pkcs15-init を使用したスマートカードのプロビジョニングは、前述の回避策を適用している場合に限り機能します。
systemd が任意のパスからコマンドを実行できない
SELinux ポリシーパッケージにはこのようなルールが含まれていないため、systemd サービスは /home/user/bin の任意のパスからコマンドを実行できません。そのため、システム以外のパスで実行されるカスタムサービスは失敗し、SELinux がアクセスを拒否すると、AVC (アクセスベクターキャッシュ) 監査メッセージをログに記録します。この問題を回避するには、以下のいずれかを実行します。
-cオプションを指定し、シェル スクリプトを使用してコマンドを実行します。以下に例を示します。bash -c command-
/bin、/sbin、/usr/sbin、/usr/local/bin、/usr/local/sbinの共通のディレクトリーを使用して共通のパスからコマンドを実行します。
selinux-policy により、IPsec が TCP で機能しないようにします。
RHEL 8.4 の libreswan パッケージは、TCP カプセル化を使用した IPsec ベースの VPN に対応します。ただし、selinux-policy パッケージでは、この更新が反映されません。これにより、Libreswan が TCP を使用するよう設定すると、ipsec サービスは指定の TCP ポートにバインドできません。
この問題を回避するには、カスタムの SELinux ポリシーを使用します。
テキストエディターで新しい
.cilファイルを開きます。以下に例を示します。# vim local_ipsec_tcp_listen.cil
以下のルールを挿入します。
(allow ipsec_t ipsecnat_port_t (tcp_socket (name_bind name_connect)))
- ファイルを保存してから閉じます。
ポリシーモジュールをインストールします。
# semodule -i local_ipsec_tcp_listen.cil
ipsecサービスを再起動します。# systemctl restart ipsec
これにより、Libreswan は、一般的に使用される 4500/tcp ポートにバインドおよび接続できます。
Server with GUI または Workstation ソフトウェアの選択と CIS セキュリティープロファイルを使用したインストールはできません。
CIS セキュリティープロファイルは、Server with GUI および Workstation ソフトウェアの選択と互換性がありません。そのため、Server with GUI ソフトウェアの選択と CIS プロファイルを使用した RHEL 8 のインストールはできません。CIS プロファイルと、これらのソフトウェアの選択のいずれかを使用したインストール試行では、エラーメッセージが生成されます。
package xorg-x11-server-common has been added to the list of excluded packages, but it can't be removed from the current software selection without breaking the installation.
この問題を回避するには、Server with GUI または Workstation ソフトウェアの選択で CIS セキュリティープロファイルを使用しないでください。
CIS プロファイルで rpm_verify_permissions が失敗する
rpm_verify_permissions ルールでは、ファイルパーミッションがパッケージのデフォルトパーミッションと比較されます。ただし、scap-security-guide パッケージで提供される Center for Internet Security (CIS) プロファイルでは、一部のファイルパーミッションがデフォルトよりも厳格なものに変更されます。その結果、rpm_verify_permissions を使用した特定ファイルの検証が失敗します。
この問題を回避するには、これらのファイルに以下のパーミッションがあることを手作業で確認します。
-
/etc/cron.d(0700) -
/etc/cron.hourly(0700) -
/etc/cron.monthly(0700) -
/etc/crontab(0600) -
/etc/cron.weekly(0700) -
/etc/cron.daily(0700)
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)
SSG における相互依存ルールの特定のセットが失敗する可能性があります。
ルールとその依存関係の順序付けを定義しないため、ベンチマークの SCAP Security Guide (SSG) ルールの修正が失敗する可能性があります。たとえば、特定の順番で複数のルールを実行する必要がある場合、あるルールがコンポーネントをインストールし、別のルールが同じコンポーネントを設定した場合すると、それらは正しくない順序で実行される可能性があり、修正によってエラーが報告されます。この問題を回避するには、修正を回実行して、番目の実行で依存ルールを修正します。
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)
キックスタートインストール時のサービス関連のルールの修正が失敗する場合があります。
キックスタートのインストール時に、OpenSCAP ユーティリティーで、サービス enable または disable 状態の修正が必要でないことが誤って表示されることがあります。これにより、OpenSCAP が、インストール済みシステムのサービスを非準拠状態に設定する可能性があります。回避策として、キックスタートインストール後にシステムをスキャンして修復できます。これにより、サービス関連の問題が修正されます。
特定の 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
したがって、現在の設定は、正しく機能する文字列に限定する必要があります。
SELinux Audit ルールと SELinux ブール値設定での競合
Audit ルールリストに、subj_* または obj_* フィールドを含む Audit ルールが含まれ、SELinux ブール値の設定が変更された場合は、SELinux ブール値を設定するとデッドロックが発生します。その結果、システムが応答しなくなり、復旧に再起動が必要になります。この問題を回避するには、subj_* または obj_* フィールドを含む Audit ルールをすべて無効にするか、SELinux ブール値を変更する前にこのようなルールを一時的に無効にします。
RHSA-2021:2168 アドバイザリーのリリースにより、カーネルはこの状況を適切に処理し、デッドロックが発生しなくなりました。
(BZ#1924230)
