11.5. セキュリティー
tangd-keygen はデフォルト以外の umask を正しく処理しません。
tangd-keygen スクリプトは、生成されたキーファイルのファイル権限を変更しません。その結果、他のユーザーへのキーの読み取りを防止するデフォルトのユーザーファイル作成モードマスク (umask) が設定されているシステムでは、tang-show-keys コマンドはキーを表示する代わりにエラーメッセージ Internal Error 500 を返します。
この問題を回避するには、chmod o+r *.jwk コマンドを使用して、/var/db/tang ディレクトリー内のファイルのアクセス許可を変更します。
PKCS #11 トークンが生の RSA または RSA-PSS 署名の作成をサポートしているかどうかを OpenSSL が検出しない
TLS 1.3 プロトコルには、RSA-PSS 署名のサポートが必要です。PKCS #11 トークンが生の RSA または RSA-PSS 署名をサポートしていない場合、キーが PKCS #11 トークンによって保持されている場合、OpenSSL ライブラリーを使用するサーバーアプリケーションは RSA キーを操作できません。これにより、上記のシナリオで TLS 通信に失敗します。
この問題を回避するには、利用可能な最高の TLS プロトコルバージョンとして TLS バージョン 1.2 を使用するようにサーバーとクライアントを設定します。
Bugzilla: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 接続を確立できます。
Bugzilla:1685470
特定の構文の使用時に 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 コンテンツの有効化だけに限定されます。
oscap-anaconda-addon では、Network Servers パッケージグループを使用したシステムの CIS 強化が許可されません。
ネットワークサーバーパッケージグループが選択されているシステムに、CIS セキュリティープロファイル (cis、cis_server_l1、cis_workstation_l1、または cis_workstation_l2) を使用して RHEL ネットワークサーバーをインストールすると、oscap-anaconda-addon によってエラーメッセージ package tftp has been added to the list of excluded packages, but it can’t be removed from the current software selection without breaking the install が送信されます。インストールを続行するには、ソフトウェアの選択に戻り、追加ソフトウェア Network Servers のチェックを外して、インストールとハードニングを終了します。次に、必要なパッケージをインストールします。
Keylime は連結された PEM 証明書を受け入れない
Keylime が単一のファイルに連結された PEM 形式の複数の証明書として証明書チェーンを受信すると、keylime-agent-rust Keylime コンポーネントは署名検証中に提供されたすべての証明書を正しく使用せず、TLS ハンドシェイクが失敗します。その結果、クライアントコンポーネント (keylime_verifier および keylime_tenant) は Keylime エージェントに接続できません。この問題を回避するには、複数の証明書ではなく 1 つの証明書だけを使用します。
Jira:RHELPLAN-157225
Keylime には tls_dir = default の特定のファイルが必要
Keylime verifier または registrar 設定で tls_dir 変数が default に設定されている場合、Keylime は /var/lib/keylime/cv_ca ディレクトリーに cacert.crt ファイルが存在するか確認します。ファイルが存在しない場合、keylime_verifier または keylime_registrar サービスは開始に失敗し、メッセージ Exception: It appears that the verifier has not yet created a CA and certificates, please run the verifier first がログに記録されます。その結果、Keylime は、ファイル名が異なるカスタム認証局 (CA) 証明書が /var/lib/keylime/ca_cv ディレクトリーに配置されている場合でも拒否します。
この問題を回避してカスタム CA 証明書を使用するには、tls_dir = default を使用する代わりに tls_dir =/var/lib/keylime/ca_cv を手動で指定します。
Jira:RHELPLAN-157337
デフォルトの 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 がデフォルトのシステムセキュリティーを下げるのを防ぎます。
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 認証エージェントとして機能します。
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 が、インストール済みシステムのサービスを非準拠状態に設定する可能性があります。回避策として、キックスタートインストール後にシステムをスキャンして修復できます。これにより、サービス関連の問題が修正されます。
