7.4. Security
リモートユーザーがスマートカードにアクセスするように繰り返し求められることはなくなりました
以前は、pcscd
デーモンの polkit
ポリシーが誤ってユーザーインタラクションを要求していました。その結果、非ローカルおよび非特権ユーザーはスマートカードにアクセスできず、多数のプロンプトが表示されました。この更新により、pcsc-lite
パッケージポリシーにインタラクティブプロンプトが含まれなくなりました。その結果、リモートカードユーザーが特権の昇格を繰り返し要求されることがなくなりました。
非特権ユーザーの特権を昇格させるためのポリシーの調整の詳細については、RHEL 製品ドキュメントの セキュリティー強化 の polkit を使用したスマートカードへのアクセスの制御 を参照してください。
FIPS モードでインストールするときに 64 ビット IBM Z システムが起動できなくなることはなくなりました
以前は、--no-bootcfg
オプションを指定した fips-mode-setup
コマンドは zipl
ツールを実行しませんでした。fips-mode-setup
は初期 RAM ディスク (initrd
) を再生成し、その結果であるシステムを起動するには zipl
内部状態を更新する必要があるため、FIPS モードでインストールした後、64 ビット IBM Z システムは起動できない状態になります。今回の更新で、--no-bootcfg
で呼び出された場合でも、fips-mode-setup
が 64 ビットの IBM Z システムで zipl
を実行するようになり、新たにインストールしたシステムが正常に起動するようになりました。
(BZ#2020295)
crypto-policies
は OpenSSL の ChaCha20 を無効にできます。
以前は、crypto-policies
コンポーネントは誤ったキーワードを使用して OpenSSL で ChaCha20 暗号を無効にしていました。そのため、crypto-policies
では、OpenSSL の TLS 1.2 で ChaCha20 の使用を無効にできませんでした。今回の更新で、crypto-policies
は、-CHACHA20-POLY1305
キーワードではなく、-CHACHA20
キーワードを使用するようになりました。その結果、crypto-policies
を使用して、TLS 1.2 と TLS 1.3 の両方で OpenSSL の ChaCha20 暗号の使用を無効にできるようになりました。
systemd
は /home/user/bin
からファイルを実行できるようになりました
以前は、SELinux ポリシーにそのようなアクセスを許可するポリシールールが含まれていなかったため、systemd
サービスは /home/user/bin/
ディレクトリーからファイルを実行できませんでした。したがって、systemd
サービスは失敗し、最終的に Access Vector Cache (AVC) を拒否する監査メッセージがログに記録されました。この更新により、欠落していたアクセスを許可する SELinux ルールが追加され、systemd
サービスが /home/user/bin/
からコマンドを正しく実行できるようになりました。
STIG 固有のデフォルトのバナーテキストが他のプロファイルから削除される
以前は、STIG プロファイルのバナーテキストは、CIS などのデフォルトテキストが定義されていない他のプロファイルによってデフォルトとして使用されていました。結果として、これらのプロファイルを使用するシステムは、DISA が要求する特定のテキストで設定されました。この更新により、一般的なデフォルトテキストが作成され、ガイドラインに沿った標準の CIS バナーが定義されました。その結果、テキストバナーを明示的に要求するガイドラインに基づくプロファイルが要件に合わせられ、正しいテキストが設定されるようになりました。
ANSSI Enhanced Profile は、"Ensure SELinux State is Enforcing" ルールを正しく選択します
以前は、ANSSI Enhanced プロファイル (anssi_bp28_enhanced
) は "Ensure SELinux State is Enforcing" (selinux_state
) ルールを選択していませんでした。この更新によりルールの選択が変更され、ANSSI Enhanced Profile が "Ensure SELinux State is Enforcing" ルールを選択するようになりました。
restorecon
および seunshareSSG
ルールの説明が修正される
以前は、"Record Any Attempts to Run restorecon" (CCE-80699-2) および "Record Any Attempts to Run seunshare" (CCE-80933-5) の説明が正しくありませんでした。今回の更新により、これらのルールの説明は自動化された OVAL チェックに合わせて調整されます。その結果、説明で推奨されている修正を適用すると、これらのルールが正しく修正されるようになりました。
CIS プロファイルが IPv6 を自動的に無効にすることはなくなる
以前、RHEL 8 の CIS プロファイルは、推奨事項 3.6 IPv6 の無効化に対して不適切な自動修復を提供していました。これは、IPv6 モジュールがロードされないように /etc/modprobe.d/ipv6.conf
を設定することで IPv6 を無効にしました。これは、依存する機能やサービスに望ましくない影響を与える可能性があります。RHEL 8 CIS Benchmark v1.0.1 では、推奨事項 3.6 を手動で実装する必要があるため、RHEL8 CIS プロファイルはこの設定アイテムの修正を適用しません。その結果、CIS プロファイルはベンチマークと整合し、IPv6 を自動的に無効にしません。CIS が推奨する GRUB2 または sysctl 設定を設定して IPv6 を手動で無効にするには、Red Hat Enterprise Linux で IPv6 プロトコルを無効または有効にするにはどうすればよいですか ? を参照してください。
(BZ#1990736)
CIS プロファイルが SSH サービスをブロックしなくなりました
以前は、xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key
ルールは、デフォルトで SSH 秘密鍵のアクセス許可を 640
に設定していました。その結果、SSH デーモンが起動しませんでした。この更新により、file_permissions_sshd_private_key
ルールが CIS プロファイルから削除され、その結果、SSH サービスが正しく機能します。
/usr/share/audit/sample-rules
内のファイルが SCAP ルールで受け入れられるようになりました
以前は、SCAP ルール xccdf_org.ssgproject.content_rule_audit_ospp_general
および xccdf_org.ssgproject.content_rule_audit_immutable_login_uids
の説明に従って、ユーザーは /usr/share/audit/sample-rules
ディレクトリーから適切なファイルをコピーすることでシステムを準拠させることができました。ただし、これらのルールの OVAL チェックは失敗したため、スキャン後にシステムは非準拠としてマークされました。この更新により、OVAL チェックは /usr/share/audit/sample-rules
からのファイルを受け入れるようになり、SCAP ルールは正常に渡されます。
ANSSI Kickstart は、十分なディスク容量を予約するようになる
以前は、GUI のインストールには、/usr
パーティションに予約されている ANSSI Kickstart よりも多くのディスクスペースが必要でした。その結果、RHEL 8.6 GUI のインストールが失敗し、At least 429 MB more space needed on the /usr filesystem
を示すエラーメッセージが表示されました。この更新により、/usr
パーティションのディスク容量が増加し、scap-security-guide
で提供されている ANSSI Kickstart を使用した RHEL8.6 のインストールが正常に完了するようになりました。
GRUB2 引数の修正が永続化される
以前は、カーネル引数を設定する GRUB2 ルールの修正は誤った手順を使用しており、設定の変更はカーネルのアップグレード間で永続的ではありませんでした。結果として、修正はカーネルのアップグレードごとに再適用する必要がありました。この更新では、修復は永続的な方法で GRUB2 を設定する grubby
ツールを使用します。
RHEL 8 ホストからリモートシステムをスキャンするときに scap-workbench
がハングしなくなりました
以前は、スキャンされたシステムにコンテンツファイルを送信するとハングし、scap-workbench
ユーティリティーがスキャンを完了できませんでした。これは、実行された Qt サブプロセスをブロックするカーネルのバグが原因でした。結果として、RHEL8 ホストから scap-workbench
コマンドを使用したリモートシステムのスキャンは機能しません。今回の更新により、根底にあるカーネルのバグが修正されたため、リモートシステムへのファイルのコピー時にリモートスキャンがハングすることがなくなり、正常に終了するようになりました。
usbguard-notifier
が Journal に記録するエラーメッセージの数が適正になりました
以前は、usbguard-notifier
サービスに usbguard-daemon
IPC インターフェイスに接続するためのプロセス間通信 (IPC) のパーミッションがありませんでした。したがって、usbguard-notifier
はインターフェイスへの接続に失敗し、対応するエラーメッセージがジャーナルに書き込まれていました。usbguard-notifier
は --wait
オプションで始まるため、デフォルトでは接続障害後に毎秒 usbguard-notifier
が IPC インターフェイスへの接続を試みるため、ログにはこれらのメッセージが過剰に含まれていました。
今回の更新により、usbguard-notifier
はデフォルトで --wait
で開始されなくなりました。サービスは、1 秒間隔で 3 回だけデーモンへの接続を試みます。その結果、ログには最大で 3 つのエラーメッセージが含まれます。
アンビエント機能が root 以外のユーザーに正しく適用されるようになりました
安全対策として、UID (ユーザー識別子) をルートから非ルートに変更すると、許可された有効な一連のアンビエント機能セットが無効になっていました。
しかし、アンビエントセットに含まれる機能は許可されたセットと継承可能なセットの両方に含まれている必要があるため、pam_cap.so
モジュールはアンビエント機能を設定できません。さらに、たとえば setuid
ユーティリティーを使用して) UID を変更すると許可されたセットが無効になるため、アンビエント機能を設定できません。
この問題を修正するために、pam_cap.so
モジュールは keepcaps
オプションをサポートするようになりました。これにより、プロセスは、UID をルートから非ルートに変更した後も許可された機能を保持できます。pam_cap.so
モジュールは、defer
オプションもサポートするようになりました。これにより、pam_cap.so
は、pam_end()
へのコールバック内でアンビエント機能を再適用します。このコールバックは、UID を変更した後、他のアプリケーションで使用できます。
そのため、su
ユーティリティーおよび login
ユーティリティーが更新済みで PAM に準拠している場合は、keepcaps
オプションおよび defer
オプションを指定して pam_cap.so
を使用し、root 以外のユーザーにアンビエント機能を設定できるようになりました。
usbguard-selinux
パッケージが usbguard
に依存しなくなりました。
usbguard-selinux
パッケージは、以前は usbguard
パッケージに依存していました。これを、このパッケージの他の依存関係と組み合わせると、usbguard
のインストール時にファイル競合が発生しました。そのため、特定システムに usbguard
がインストールされなくなりました。このバージョンでは、usbguard-selinux
が usbguard
に依存しなくなったため、yum
が usbguard
を正しくインストールできるようになりました。
audisp-remote
は、リモートロケーションの可用性を正しく検出するようになりました
以前は、audisp-remote
プラグインは、リモートサービスが利用できなくなったことを検出しませんでした。その結果、audisp-remote
プロセスの CPU 使用率が高くなっていました。今回の更新で、audisp-remote
は利用できなくなったリモートサービスを適切に検出できまるようになりました。したがって、プロセスの CPU 使用率は高くなりません。
自動ロック解除前に特定の設定で Clevis が停止しなくなりました
以前は、LUKS で暗号化されたボリュームの自動ロック解除を実行する Clevis ユーティリティーは、特定のシステム設定で停止していました。そのため、暗号化されたボリュームは自動的にロック解除されず、管理者はパスフレーズを手動で提供する必要がありました。場合によっては、管理者が Enter キーを押して暗号化されたボリュームのロックを解除しなければ、Clevis は再起動しませんでした。今回の更新で、ユーティリティーはこれらの設定で停止しないように修正され、自動ロック解除のプロセスが正しく機能するようになりました。
(BZ#2018292)