10.2. セキュリティー
4 つの libvirt
サービスの SELinux ポリシールールが一時的に permissive モードに変更される
以前は、SELinux ポリシーは、従来のモノリシック libvirtd
デーモンを新しいモジュラーデーモンセットに置き換えたことを反映して変更されていました。この変更にはいくつかのシナリオのテストが必要になるため、次のサービスは一時的に SELinux の permissive モードに変更されていました。
-
virtqemud
-
virtvboxd
-
virtstoraged
-
virtsecretd
無害な AVC 拒否を防ぐために、これらのサービスの SELinux ポリシーに dontaudit
ルールが追加されました。
Jira:RHEL-77808[1]
pkcs11-provider
を使用した FIPS モードで暗号化トークンが動作しない
システムが FIPS モードで実行されている場合、pkcs11-provider
OpenSSL プロバイダーは正しく動作せず、OpenSSL TLS ツールキットはデフォルトのプロバイダーにフォールバックします。その結果、OpenSSL は PKCS #11 キーをロードできず、このシナリオでは暗号化トークンは機能しません。
回避策: openssl.cnf
ファイルの PKCS #11 セクションで pkcs11-module-assume-fips = true
パラメーターを設定します。詳細は、システムの pkcs11-provider(7)
man ページを参照してください。この設定変更により、pkcs11-provider
は FIPS モードで動作するようになります。
Extended Master Secret
TLS エクステンションが FIPS 対応システムに適用されるようになりました。
RHSA-2023:3722 アドバイザリーのリリースにより、FIPS 対応の RHEL 9 および 10 システム上の TLS 1.2 接続に、TLS Extended Master Secret
(EMS) 拡張機能 (RFC 7627) が必須になりました。これは FIPS-140-3 要件に準拠しています。TLS 1.3 は影響を受けません。
EMS または TLS 1.3 をサポートしていないレガシークライアントは、RHEL 9 および 10 で稼働する FIPS サーバーに接続できなくなりました。同様に、FIPS モードの RHEL 9 および 10 クライアントは、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 を参照してください。
NSS データベースのパスワードを更新すると ML-DSA のシードが破損する
ML-DSA 鍵の生成は、鍵を導出するのに十分なシードから始まります。ただし、後続の操作を高速化するために、鍵を拡張することもできます。NSS データベースに ML-DSA 鍵 (生成またはインポートしたもの) がある場合、拡張形式とシードの両方が保存されている可能性があります。NSS がデータベースの再暗号化を処理する方法にバグがあるため、データベースのパスワードを変更すると、シード属性が新しいパスワードに合わせて更新されません。その結果、以前のパスワードを知っていたとしても、シードの値は永久に失われます。
回避策: パスワードを更新する前に鍵をエクスポートし、更新後に再度インポートします。