11.2. セキュリティー
OpenSSL は PKCS #11 トークンが raw RSA または RSA-PSS 署名の作成をサポートしているか検出しない
TLS 1.3 プロトコルには、RSA-PSS 署名のサポートが必要です。PKCS #11 トークンが生の RSA または RSA-PSS 署名をサポートしていない場合、キーが PKCS #11 トークンによって保持されている場合、OpenSSL ライブラリーを使用するサーバーアプリケーションは RSA キーを操作できません。これにより、上記のシナリオで TLS 通信に失敗します。
この問題を回避するには、利用可能な最高の TLS プロトコルバージョンとして TLS バージョン 1.2 を使用するようにサーバーとクライアントを設定します。
Bugzilla:1681178[1]
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 接続を確立できます。
Bugzilla:1685470[1]
特定の構文を使用すると、scp は 自身にコピーされたファイルを空にする
scp ユーティリティーが Secure copy protocol (SCP) からよりセキュアな SSH ファイル転送プロトコル (SFTP) に変更されました。したがって、ある場所からファイルを同じ場所にコピーすると、ファイルの内容が消去されます。この問題は以下の構文に影響します。
scp localhost:/myfile localhost:/myfile
この問題を回避するには、この構文を使用して、ソースの場所と同じ宛先にファイルをコピーしないでください。
この問題は、以下の構文に対して修正されました。
-
scp /myfile localhost:/myfile -
scp localhost:~/myfile ~/myfile
OSCAP Anaconda アドオンは、グラフィカルインストールで調整されたプロファイルをフェッチしない
OSCAP Anaconda アドオンには、RHEL グラフィカルインストールでセキュリティープロファイルの調整を選択または選択解除するオプションがありません。RHEL 8.8 以降、アドオンはアーカイブまたは RPM パッケージからインストールするときにデフォルトで調整を考慮しません。その結果、インストールでは、OSCAP に合わせたプロファイルを取得する代わりに、次のエラーメッセージが表示されます。
There was an unexpected problem with the supplied content.
この問題を回避するには、キックスタートファイルの %addon org_fedora_oscap セクションにパスを指定する必要があります。次に例を示します。
xccdf-path = /usr/share/xml/scap/sc_tailoring/ds-combined.xml tailoring-path = /usr/share/xml/scap/sc_tailoring/tailoring-xccdf.xml
その結果、OSCAP 調整プロファイルのグラフィカルインストールは、対応するキックスタート仕様のみで使用できます。
Ansible 修復には追加のコレクションが必要
ansible-core パッケージによる Ansible Engine の置き換えにより、RHEL サブスクリプションで提供される Ansible モジュールのリストが削減されました。これにより、scap-security-guide パッケージに含まれる Ansible コンテンツを使用する修復を実行するには、rhc-worker-playbook パッケージからのコレクションが必要です。
Ansible 修復の場合は、以下の手順を実行します。
必要なパッケージをインストールします。
# dnf install -y ansible-core scap-security-guide rhc-worker-playbook
/usr/share/scap-security-guide/ansibleディレクトリーに移動します。# cd /usr/share/scap-security-guide/ansible
追加の Ansible コレクションへのパスを定義する環境変数を使用して、関連する Ansible Playbook を実行します。
# ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/ ansible-playbook -c local -i localhost, rhel9-playbook-cis_server_l1.ymlcis_server_l1を、システムを修正するプロファイルの ID に置き換えます。
これにより、Ansible コンテンツは正しく処理されます。
rhc-worker-playbook で提供されるコレクションのサポートは、scap-security-guide から取得する Ansible コンテンツの有効化だけに限定されます。
Keylime は連結された PEM 証明書を受け入れない
Keylime が単一のファイルに連結された PEM 形式の複数の証明書として証明書チェーンを受信すると、keylime-agent-rust Keylime コンポーネントは署名検証中に提供されたすべての証明書を正しく使用せず、TLS ハンドシェイクが失敗します。その結果、クライアントコンポーネント (keylime_verifier および keylime_tenant) は Keylime エージェントに接続できません。この問題を回避するには、複数の証明書ではなく 1 つの証明書だけを使用します。
Jira:RHELPLAN-157225[1]
Keylime は、ダイジェストがバックスラッシュで始まるランタイムポリシーを拒否する
ランタイムポリシーを生成する現在のスクリプト create_runtime_policy.sh は、SHA チェックサム関数 (sha256sum など) を使用してファイルダイジェストを計算します。ただし、入力ファイル名にバックスラッシュまたは \n が含まれている場合、チェックサム関数は出力のダイジェストの前にバックスラッシュを追加します。このような場合、生成されたポリシーファイルの形式は不正になります。不正な形式のポリシーファイルが提供されると、Keylime テナントは、エラーメッセージ me.tenant - ERROR - Response code 400: Runtime policy is malformatted (または同様のエラーメッセージ) を生成します。この問題を回避するには、sed -i 's/^\\//g' <malformed_file_name> コマンドを入力して、不正な形式のポリシーファイルからバックスラッシュを手動で削除します。
Jira:RHEL-11867[1]
Keylime エージェントが更新後に verifier からのリクエストを拒否する
Keylime エージェント (keylime-agent-rust) の API バージョン番号が更新されると、エージェントは別のバージョンを使用するリクエストを拒否します。その結果、Keylime エージェントが verifier に追加されて更新されると、verifier は古い API バージョンを使用してエージェントに接続しようとします。エージェントはこのリクエストを拒否し、認証に失敗します。この問題を回避するには、エージェント (keylime-agent-rust) を更新する前に verifier (keylime-verifier) を更新します。その結果、エージェントが更新されると、verifier は API の変更を検出し、それに応じて保存されているデータを更新します。
Jira:RHEL-1518[1]
fapolicyd ユーティリティーは、変更されたファイルの実行を誤って許可する
正しくは、ファイルの IMA ハッシュはファイルに変更が加えられた後に更新され、fapolicyd は変更されたファイルの実行を阻止する必要があります。ただし、IMA ポリシーのセットアップと evctml ユーティリティーによるファイルハッシュの違いにより、これは起こりません。その結果、変更されたファイルの拡張属性で IMA ハッシュは更新されません。その結果、fapolicyd は、変更されたファイルの実行を誤って許可します。
Jira:RHEL-520[1]
デフォルトの SELinux ポリシーにより、制限のない実行ファイルがスタックを実行可能にする
SELinux ポリシーの selinuxuser_execstack ブール値のデフォルトの状態は on です。これは、制限のない実行ファイルがスタックを実行可能にすることを意味します。実行可能ファイルはこのオプションを使用しないでください。また、ハードコーディングされていない実行ファイルや攻撃の可能性を示している可能性があります。ただし、他のツール、パッケージ、およびサードパーティー製品との互換性のため、Red Hat はデフォルトポリシーのブール値を変更できません。そのような互換性の側面に依存しない場合は、コマンド setsebool -P selinuxuser_execstack off を入力して、ローカルポリシーでブール値をオフにすることができます。
STIG プロファイルの SSH タイムアウトルールが誤ったオプションを設定する
OpenSSH の更新は、次の米国国防情報システム局のセキュリティー技術実装ガイド (DISA STIG) プロファイルのルールに影響を与えました。
-
RHEL 9 用 DISA STIG (
xccdf_org.ssgproject.content_profile_stig) -
RHEL 9 用、GUI の DISA STIG (
xccdf_org.ssgproject.content_profile_stig_gui)
これらの各プロファイルでは、次の 2 つのルールが影響を受けます。
Title: Set SSH Client Alive Count Max to zero CCE Identifier: CCE-90271-8 Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_keepalive_0 Title: Set SSH Idle Timeout Interval CCE Identifier: CCE-90811-1 Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_idle_timeout
SSH サーバーに適用すると、これらの各ルールは、以前のように動作しなくなったオプション (ClientAliveCountMax および ClientAliveInterval) を設定します。その結果、OpenSSH は、これらのルールで設定されたタイムアウトに達したときに、アイドル状態の SSH ユーザーを切断しなくなりました。回避策として、これらのルールは、ソリューションが開発されるまで、DISA STIG for RHEL 9 および DISA STIG with GUI for RHEL 9 プロファイルから一時的に削除されました。
GnuPG は crypto-policies によって許可されていない場合でも、SHA-1 署名の使用を誤って許可する
GNU Privacy Guard (GnuPG) 暗号化ソフトウェアは、システム全体の暗号化ポリシーで定義されている設定に関係なく、SHA-1 アルゴリズムを使用する署名を作成および検証できます。したがって、DEFAULT の暗号化ポリシーで暗号化の目的で SHA-1 を使用できます。これは、署名に対するこのセキュアではないアルゴリズムのシステム全体での非推奨とは一致しません。
この問題を回避するには、SHA-1 を含む GnuPG オプションを使用しないでください。これにより、セキュアでない SHA-1 署名を使用して GnuPG がデフォルトのシステムセキュリティーを下げるのを防ぎます。
OpenSCAP のメモリー消費の問題
メモリーが限られているシステムでは、OpenSCAP スキャナが途中で停止するか、結果ファイルが生成されない可能性があります。この問題を回避するには、スキャンプロファイルをカスタマイズして、/ ファイルシステム全体の再帰を含むルールの選択を解除します。
-
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 ユーティリティーで、サービス enable または disable 状態の修正が必要でないことが誤って表示されることがあります。これにより、OpenSCAP が、インストール済みシステムのサービスを非準拠状態に設定する可能性があります。回避策として、キックスタートインストール後にシステムをスキャンして修復できます。これにより、サービス関連の問題が修正されます。
