11.2. セキュリティー

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^[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

SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384
MaxProtocol = TLSv1.2

Copy to Clipboard

Toggle word wrap

これにより、このシナリオで 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

Bugzilla:2056884

OSCAP Anaconda アドオンは、グラフィカルインストールで調整されたプロファイルをフェッチしない

OSCAP Anaconda アドオンには、RHEL グラフィカルインストールでセキュリティープロファイルの調整を選択または選択解除するオプションがありません。RHEL 8.8 以降、アドオンはアーカイブまたは RPM パッケージからインストールするときにデフォルトで調整を考慮しません。その結果、インストールでは、OSCAP に合わせたプロファイルを取得する代わりに、次のエラーメッセージが表示されます。

There was an unexpected problem with the supplied content.

There was an unexpected problem with the supplied content.

Copy to Clipboard

Toggle word wrap

この問題を回避するには、キックスタートファイルの %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

xccdf-path = /usr/share/xml/scap/sc_tailoring/ds-combined.xml
tailoring-path = /usr/share/xml/scap/sc_tailoring/tailoring-xccdf.xml

Copy to Clipboard

Toggle word wrap

その結果、OSCAP 調整プロファイルのグラフィカルインストールは、対応するキックスタート仕様のみで使用できます。

Jira:RHEL-1824

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

# dnf install -y ansible-core scap-security-guide rhc-worker-playbook

Copy to Clipboard

Toggle word wrap

/usr/share/scap-security-guide/ansible ディレクトリーに移動します。
```
cd /usr/share/scap-security-guide/ansible
```
```
# cd /usr/share/scap-security-guide/ansible
```
Copy to Clipboard Toggle word wrap

追加の 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.yml

# ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/ ansible-playbook -c local -i localhost, rhel9-playbook-cis_server_l1.yml

Copy to Clipboard

Toggle word wrap

cis_server_l1 を、システムを修正するプロファイルの ID に置き換えます。

これにより、Ansible コンテンツは正しく処理されます。

注記

rhc-worker-playbook で提供されるコレクションのサポートは、scap-security-guide から取得する Ansible コンテンツの有効化だけに限定されます。

Jira:RHEL-1800

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]

trustdb にファイルが見つからないため、fapolicyd が拒否される

fapolicyd が Ansible DISA STIG プロファイルとともにインストールされると、競合状態により trustdb データベースが rpmdb データベースと同期しなくなります。その結果、trustdb 内のファイルが見つからないと、システムで拒否が発生します。この問題を回避するには、fapolicyd を再起動するか、Ansible DISA STIG プロファイルを再度実行します。

Jira:RHEL-24345^[1]

fapolicyd ユーティリティーは、変更されたファイルの実行を誤って許可する

正しくは、ファイルの IMA ハッシュはファイルに変更が加えられた後に更新され、fapolicyd は変更されたファイルの実行を阻止する必要があります。ただし、IMA ポリシーのセットアップと evctml ユーティリティーによるファイルハッシュの違いにより、これは起こりません。その結果、変更されたファイルの拡張属性で IMA ハッシュは更新されません。その結果、fapolicyd は、変更されたファイルの実行を誤って許可します。

Jira:RHEL-520^[1]

OpenSSL で X.509 v1 証明書を作成できなくなる

RHEL 9.5 で導入された OpenSSL TLS ツールキット 3.2.1 では、openssl CA ツールを使用して X.509 バージョン 1 形式の証明書を作成できなくなりました。X.509 v1 形式は現在の Web 要件を満たしていません。

Jira:RHEL-40605

OpenSSH は認証前にタイムアウトを記録しなくなる

OpenSSH は、$IP port $PORT の認証前のタイムアウトをログに記録しません。Fail2Ban 侵入防止デーモンや同様のシステムが、これらのログ記録を mdre-ddos 正規表現で使用し、このタイプの攻撃を試みるクライアントの IP を禁止しなくなったため、これは重要かもしれません。現在、この問題に対する既知の回避策はありません。

Jira:RHEL-45727

デフォルトの SELinux ポリシーにより、制限のない実行ファイルがスタックを実行可能にする

SELinux ポリシーの selinuxuser_execstack ブール値のデフォルトの状態は on です。これは、制限のない実行ファイルがスタックを実行可能にすることを意味します。実行可能ファイルはこのオプションを使用しないでください。また、ハードコーディングされていない実行ファイルや攻撃の可能性を示している可能性があります。ただし、他のツール、パッケージ、およびサードパーティー製品との互換性のため、Red Hat はデフォルトポリシーのブール値を変更できません。そのような互換性の側面に依存しない場合は、コマンド setsebool -P selinuxuser_execstack off を入力して、ローカルポリシーでブール値をオフにすることができます。

Bugzilla:2064274

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

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

Copy to Clipboard

Toggle word wrap

SSH サーバーに適用すると、これらの各ルールは、以前のように動作しなくなったオプション (ClientAliveCountMax および ClientAliveInterval) を設定します。その結果、OpenSSH は、これらのルールで設定されたタイムアウトに達したときに、アイドル状態の SSH ユーザーを切断しなくなりました。回避策として、これらのルールは、ソリューションが開発されるまで、DISA STIG for RHEL 9 および DISA STIG with GUI for RHEL 9 プロファイルから一時的に削除されました。

Bugzilla:2038978

GnuPG は crypto-policies によって許可されていない場合でも、SHA-1 署名の使用を誤って許可する

GNU Privacy Guard (GnuPG) 暗号化ソフトウェアは、システム全体の暗号化ポリシーで定義されている設定に関係なく、SHA-1 アルゴリズムを使用する署名を作成および検証できます。したがって、DEFAULT の暗号化ポリシーで暗号化の目的で SHA-1 を使用できます。これは、署名に対するこのセキュアではないアルゴリズムのシステム全体での非推奨とは一致しません。

この問題を回避するには、SHA-1 を含む GnuPG オプションを使用しないでください。これにより、セキュアでない SHA-1 署名を使用して GnuPG がデフォルトのシステムセキュリティーを下げるのを防ぎます。

Bugzilla:2070722

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

詳細とその他の回避策は、関連するナレッジベースの記事を参照してください。

Bugzilla:2161499

キックスタートインストール時のサービス関連ルールの修正が失敗する場合がある

キックスタートインストール時に、OpenSCAP ユーティリティーで、サービスの enable または disable 状態の修正は不要であると誤って表示されることがあります。その結果、OpenSCAP によって、インストール済みシステム上のサービスが非準拠状態に設定される可能性があります。回避策として、キックスタートインストール後にシステムをスキャンして修復できます。これにより、サービス関連の問題が修正されます。

Jira:RHELPLAN-44202^[1]

CNSA 1.0 により FIPS:OSPP ホストの相互運用性が影響を受ける

OSPP サブポリシーは、Commercial National Security Algorithm (CNSA) 1.0 に準拠しています。これは、FIPS:OSPP ポリシーとサブポリシーの組み合わせを使用するホストの相互運用性に影響します。主に影響を受ける点は次のとおりです。

RSA キーの最小サイズは 3072 ビットとすることが必要です。
アルゴリズムネゴシエーションでは、AES-128 暗号、secp256r1 Elliptic Curve、および FFDHE-2048 グループがサポートされなくなりました。

Jira:RHEL-2735^[1]

SELinux ポリシーにルールがないため、SQL データベースへの権限がブロックされる

SELinux ポリシーの権限ルールが欠落していると、SQL データベースへの接続がブロックされます。その結果、FIDO Device Onboard (FDO) サービスの fdo-manufacturing-server.service、fdo-owner-onboarding-server.service、および fdo-rendezvous-server.service が、PostgreSQL や SQLite などの FDO データベースに接続できません。したがって、システムは、所有権バウチャーの保存などの認証情報やその他のパラメーターにサポートされているデータベースを使用して FDO を起動することができません。

この問題を回避するには、次の手順に従います。

local_fdo_update.cil という名前の新しいファイルを作成し、欠落している SELinux ポリシールールを入力します。

(allow fdo_t etc_t (file (write)))
(allow fdo_t fdo_conf_t (file (append create rename setattr unlink write )))
(allow fdo_t fdo_var_lib_t (dir (add_name remove_name write )))
(allow fdo_t fdo_var_lib_t (file (create setattr unlink write )))
(allow fdo_t krb5_keytab_t (dir (search)))
(allow fdo_t postgresql_port_t (tcp_socket (name_connect)))
(allow fdo_t sssd_t (unix_stream_socket (connectto)))
(allow fdo_t sssd_var_run_t (sock_file (write)))

(allow fdo_t etc_t (file (write)))
(allow fdo_t fdo_conf_t (file (append create rename setattr unlink write )))
(allow fdo_t fdo_var_lib_t (dir (add_name remove_name write )))
(allow fdo_t fdo_var_lib_t (file (create setattr unlink write )))
(allow fdo_t krb5_keytab_t (dir (search)))
(allow fdo_t postgresql_port_t (tcp_socket (name_connect)))
(allow fdo_t sssd_t (unix_stream_socket (connectto)))
(allow fdo_t sssd_var_run_t (sock_file (write)))

Copy to Clipboard

Toggle word wrap

ポリシーモジュールパッケージをインストールします。
```
semodule -i local_fdo_update.cil
```
```
# semodule -i local_fdo_update.cil
```
Copy to Clipboard Toggle word wrap

これにより、FDO が PostgreSQL データベースに接続できるようになります。また、SQLite データベースファイルの想定される配置先である /var/lib/fdo/ の SQLite 権限に関連する問題も修正されます。

Jira:RHEL-28814

RHEL 9.0-9.3 の OpenSSH に OpenSSL 3.2.2 との互換性がない

RHEL 9.0、9.1、9.2、9.3 で提供される openssh パッケージは、OpenSSL のバージョンを厳密にチェックします。そのため、openssl パッケージをバージョン 3.2.2 以上にアップグレードし、openssh パッケージをバージョン 8.7p1-34.el9_3.3 以前のままにしておくと、OpenSSL version mismatch というエラーメッセージが表示され、sshd サービスの起動が失敗します。

この問題を回避するには、openssh パッケージをバージョン 8.7p1-38.el9 以降にアップグレードします。詳細は、sshd not working, OpenSSL version mismatch ソリューション (Red Hat ナレッジベース) を参照してください。

Jira:RHELDOCS-19626

Extended Master Secret TLS エクステンションが FIPS 対応システムに適用されるようになりました。

RHSA-2023:3722 アドバイザリーのリリースにより、FIPS 対応 RHEL 9 システム上の TLS 1.2 接続に、TLS Extended Master Secret (EMS) エクステンション (RFC 7627) エクステンションが必須になりました。これは FIPS-140-3 要件に準拠しています。TLS 1.3 は影響を受けません。

EMS または TLS 1.3 をサポートしていないレガシークライアントは、RHEL 9 で実行されている FIPS サーバーに接続できなくなりました。同様に、FIPS モードの RHEL 9 クライアントは、EMS なしでは TLS 1.2 のみをサポートするサーバーに接続できません。これは実際には、これらのクライアントが RHEL 6、RHEL 7、および RHEL 以外のレガシーオペレーティングシステム上のサーバーに接続できないことを意味します。これは、OpenSSL のレガシー 1.0.x バージョンが EMS または TLS 1.3 をサポートしていないためです。

さらに、ハイパーバイザーが EMS なしで TLS 1.2 を使用する場合は、FIPS 対応 RHEL クライアントから VMWare ESX などのハイパーバイザーへの接続が Provider routines::ems not enabled エラーで失敗するようになりました。この問題を回避するには、EMS 拡張で TLS 1.3 または TLS 1.2 をサポートするようにハイパーバイザーを更新します。VMWare vSphere の場合、これはバージョン 8.0 以降を意味します。

詳細は、TLS Extension "Extended Master Secret" enforced with Red Hat Enterprise Linux 9.2 and later を参照してください。

Jira:RHEL-13340

11.2. セキュリティー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links