11.6. セキュリティー
OpenSSL は、PKCS #11 トークンが、生の RSA 署名または RSA-PSS 署名の作成に対応しているかどうかを検出しません。
TLS 1.3 プロトコルには、RSA-PSS 署名のサポートが必要です。PKCS#11 トークンが生の RSA または RSA-PSS 署名をサポートしていない場合、キーが PKCS#11 トークンによって保持されていると、OpenSSL ライブラリーを使用するサーバーアプリケーションは RSA キーを処理できません。これにより、上記のシナリオで TLS 通信に失敗します。
この問題を回避するには、利用可能な最高の TLS プロトコルバージョンとして TLS バージョン 1.2 を使用するようにサーバーとクライアントを設定します。
(BZ#1681178)
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 接続を確立できます。
(BZ#1685470)
特定の構文の使用時に scp はコピーされたファイルを空にします
scp ユーティリティーが Secure copy protocol (SCP) からよりセキュアな SSH ファイル転送プロトコル (SFTP) に変更されました。したがって、ある場所からファイルを同じ場所にコピーすると、ファイルの内容が消去されます。この問題は以下の構文に影響します。
scp localhost:/myfile localhost:/myfile
この問題を回避するには、この構文を使用して、ソースの場所と同じ宛先にファイルをコピーしないでください。
この問題は、以下の構文に対して修正されました。
-
scp /myfile localhost:/myfile -
scp localhost:~/myfile ~/myfile
PSK 暗号スイートは FUTURE 暗号ポリシーでは機能しません
事前共有キー (PSK) 暗号スイートは、完全転送秘密 (PFS) キー交換方式を実行しているとは認識されません。結果として、ECDHE-PSK および DHE-PSK 暗号スイートは、SECLEVEL=3 に設定された OpenSSL、たとえば FUTURE 暗号化ポリシーでは機能しません。回避策として、PSK 暗号スイートを使用するアプリケーションに対して、制限の少ない暗号化ポリシーを設定するか、セキュリティーレベル (SECLEVEL) を低く設定することができます。
GnuPG は、crypto-policies によって許可されていない場合でも、SHA-1 署名の使用を誤って許可します
GNU Privacy Guard (GnuPG) 暗号化ソフトウェアは、システム全体の暗号化ポリシーで定義されている設定に関係なく、SHA-1 アルゴリズムを使用する署名を作成および検証できます。したがって、DEFAULT の暗号化ポリシーで暗号化の目的で SHA-1 を使用できます。これは、署名に対するこのセキュアではないアルゴリズムのシステム全体での非推奨とは一致しません。
この問題を回避するには、SHA-1 を含む GnuPG オプションを使用しないでください。これにより、セキュアでない SHA-1 署名を使用して GnuPG がデフォルトのシステムセキュリティーを下げるのを防ぎます。
GPG-agent が FIPS モードで SSH エージェントとして動作しない
gpg-agent ツールは、FIPS モードが MD5 ダイジェストが無効であっても ssh-agent プログラムにキーを追加する際に MD5 フィンガープリントを作成します。その結果、ssh-add ユーティリティーは認証エージェントへのキーの追加に失敗します。
この問題を回避するには、~/.gnupg/sshcontrol ファイルを gpg-agent --daemon --enable-ssh-support コマンドを使用せずに作成します。たとえば、gpg --list-keys コマンドの出力を <FINGERPRINT> 0 形式で ~/.gnupg/sshcontrol に貼り付けることができます。これにより、gpg-agent は SSH 認証エージェントとして機能します。
デフォルトの SELinux ポリシーにより、制限のない実行ファイルがスタックを実行可能にする
SELinux ポリシーの selinuxuser_execstack ブール値のデフォルトの状態は on です。これは、制限のない実行ファイルがスタックを実行可能にすることを意味します。実行可能ファイルはこのオプションを使用しないでください。また、ハードコーディングされていない実行ファイルや攻撃の可能性を示している可能性があります。ただし、他のツール、パッケージ、およびサードパーティー製品との互換性のため、Red Hat はデフォルトポリシーのブール値を変更できません。シナリオがそのような互換性の側面に依存しない場合は、コマンド setsebool -P selinuxuser_execstack off を入力して、ローカルポリシーでブール値をオフにすることができます。
キックスタートインストール時のサービス関連のルールの修正が失敗する場合があります。
キックスタートのインストール時に、OpenSCAP ユーティリティーで、サービス enable または disable 状態の修正が必要でないことが誤って表示されることがあります。これにより、OpenSCAP が、インストール済みシステムのサービスを非準拠状態に設定する可能性があります。回避策として、キックスタートインストール後にシステムをスキャンして修復できます。これにより、サービス関連の問題が修正されます。
SCAP 監査ルールの修正が失敗する
監査設定に関連する一部の SCAP ルールの bash 修復では、修正時に監査キーが追加されません。これは、以下のルールに適用されます。
-
audit_rules_login_events -
audit_rules_login_events_faillock -
audit_rules_login_events_lastlog -
audit_rules_login_events_tallylog -
audit_rules_usergroup_modification -
audit_rules_usergroup_modification_group -
audit_rules_usergroup_modification_gshadow -
audit_rules_usergroup_modification_opasswd -
audit_rules_usergroup_modification_passwd -
audit_rules_usergroup_modification_shadow -
audit_rules_time_watch_localtime -
audit_rules_mac_modification -
audit_rules_networkconfig_modification -
audit_rules_sysadmin_actions -
audit_rules_session_events -
audit_rules_sudoers -
audit_rules_sudoers_d
そのため、関連する監査ルールがすでに存在しているものの、OVAL チェックに完全に準拠していない場合、修復により監査ルールの機能部分が修正され、パスとアクセスビットが監査キーを追加しません。したがって、生成される監査ルールは正常に機能しますが、SCAP ルールは FAIL を誤って報告します。この問題を回避するには、正しいキーを監査ルールに手動で追加します。
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 プロファイルから一時的に削除されました。
Keylime は、複数の IMA 測定ファイルにアクセスするシステムの認証に失敗する可能性があります
Keylime エージェントを実行するシステムが Integrity Measurement Architecture (IMA) によって測定された複数のファイルにすばやく連続してアクセスする場合、Keylime ベリファイアは IMA ログの追加を誤って処理する可能性があります。その結果、実行中のハッシュが正しいプラットフォーム設定レジスタ (PCR) の状態と一致せず、システムは設定証明に失敗します。現在、回避策はありません。
Keylim 測定ブートポリシー生成スクリプトにより、セグメンテーションエラーとコアダンプが発生することがある
Keylime で起動認証を測定するためのポリシーを生成する create_mb_refstate スクリプトは、提供された入力に応じて tpm2_eventlog ツールの出力を処理するときに、LengthOfDevicePath フィールドの値を使用する代わりに、DevicePath フィールドのデータ長を誤って計算する場合があります。その結果、スクリプトは誤って計算された長さを使用して無効なメモリーにアクセスしようとし、その結果、セグメンテーションエラーとコアダンプが発生します。Keylime の主な機能はこの問題の影響を受けませんが、測定されたブートポリシーを生成できない可能性があります。
この問題を回避するには、メジャーブートポリシーを使用しないか、tpm2-tools パッケージの tpm2_eventlog ツールを使用して取得したデータから手動でポリシーファイルを作成します。
一部の TPM 証明書により Keylime レジストラーがクラッシュする
本番デプロイメントで有効にする必要がある tenant.conf の require_ek_cert 設定オプションは、Keylime テナントが Trusted Platform Module (TPM) からの承認キー (EK) 証明書を必要とするかどうかを決定します。require_ek_cert を有効にして最初のアイデンティティクォートを実行すると、Kelime は、EK 証明書を Keylime TPM 証明書ストアに存在する信頼できる証明書と比較して、エージェント上の TPM デバイスが本物であるかどうかを検証しようとします。ただし、ストア内の一部の証明書は不正な形式の x509 証明書であり、Keylime レジストラーがクラッシュする原因となります。require_ek_cert を false に設定し、EK 検証を実行する ek_check_script オプションでカスタムスクリプトを定義することを除いて、現在、この問題に対する簡単な回避策はありません。
