crypto-policiesは徐々に拡張されている話

森若です。

Red Hat Enterprise Linux 8（RHEL 8）は、セキュリティを強化するために多くの新機能を導入しましたが、その中でも特に運用の手間削減、セキュリティの一貫性向上、従来からの手順変更という点で運用管理への影響が大きいものがcrypto-policies(システム全体の暗号化ポリシー)です。この記事では、crypto-policiesがどのように拡張されてきたかを紹介します。

Crypto-Policiesとは？

背景としては、システムに含まれる多数のアプリケーション全体について暗号化などのレベルを揃えることが重要です。一部のサービスだけが強い暗号化を使っていても他のサービスが脆弱な暗号化を使っていると、システム全体としては脆弱です。一言で「揃える」と言っても、実際にシステムに多数存在する暗号化ライブラリやアプリケーションの設定を実施するには必要な知識が非常に幅広く難しいです。crypto-policiesはこの困難な作業を容易にするために開発されました。

Crypto-policiesは、システム全体の暗号化ポリシーを一元管理するためのフレームワークです。管理者は複数のアプリケーションやライブラリにわたって一貫した暗号化設定を簡単に適用できます。ソフトウェアの設定方法が多数のソフトウェアで従来とは変わりますから、構築手順や運用管理への影響が大きくなります。

Crypto-Policiesで設定を管理されるソフトウェアは何？

Crypto-policiesは、RHELに同梱されるOpenSSL、GnuTLS、OpenSSH、OpenJDKなど、多くのセキュリティライブラリやツールの設定を管理します。これにより、システム全体でセキュリティ基準を統一することが可能になります。crypto-policiesパッケージで設定を生成し、暗号化機能を持つ他のパッケージではcrypto-policiesの設定を読みこむ実装がおこなわれています。

管理対象とならないソフトウェアとしては、RHEL同梱以外のサードパーティソフトウェアのうち、RHEL同梱の暗号化ライブラリを使わず独自にもつものや、独自に明示的な設定を行うもの、Go言語で記述されたプログラムのほとんどです。(RHEL同梱のPodmanではcrypto-policiesの設定を反映するopensslを利用する修正がおこなわれています。)

RHEL 8.0でのCrypto-Policies

RHEL 8.0がリリースされた当初、crypto-policiesはDEFAULT、LEGACY、FUTURE、およびFIPSの4種類の事前定義されたポリシーから選択することしかできませんでした。これらのポリシーはカスタマイズすることができません。

以下のようなコマンドでポリシーを設定します。

# update-crypto-policies --set DEFAULT

RHEL 8.2でのカスタマイズ導入

RHEL 8.2から、ポリシー言語を使用してcrypto-policiesをのポリシーをユーザが定義する機能が導入されました。以下の例のような簡単な記述で、管理者はポリシーを自作したり、特定の要件に合わせてポリシーを細かく調整できるようになりました。ポリシー言語は「オプション = 暗号化スイート名(オプションによっては複数)」「オプション = 値」のような記述を列挙するものです。

典型的にはポリシーをゼロから新規に書かず、もとのポリシーからの変更部分をサブポリシーとして定義して、既存のポリシーとくみあわせて利用します。サブポリシーでは通常のポリシーの記述のほかに、もとのポリシー差分を定義して、「オプション = +値」「オプション = -値」のような記述で一部の値を追加・削除もできます。サブポリシーは任意の数だけ指定できます。

たとえば NO-SHA1.pmod でSHA-1の利用を禁止するサブポリシーを記述します。この例ではハッシュ関数、署名、証明書でのSHA-1の利用を禁止しています。ポリシー言語の詳細は man crypto-policies の CRYPTO POLICY DEFINITION FORMATに説明があります。

hash = -SHA1
sign = -*-SHA1
sha1_in_certs = 0

以下のようにくみあわせて、基本はDEFAULTポリシーですが、SHA-1の利用を禁止するポリシーを指定できます。

# update-crypto-policies --set DEFAULT:NO-SHA1

RHEL 8.5でのスコープ指定導入

RHEL 8.4まではシステム全体で統一されたポリシーしか扱えませんでした。本来の目的からすると妥当なのですが、問題となるケースが存在しました。「古いシステムから接続をうけつけるためsshだけ脆弱な暗号化を使いたい」「古いActive Directoryを利用するためKerberosだけ脆弱なハッシュ関数を使いたい」などのケースです。

RHEL 8.5からは、ポリシー言語の中で cipher@ssh のように特定のスコープを指定して、一部のプログラムにだけ影響するポリシーを設定できるようになりました。これにより、たとえばSSH接続に対する暗号化要件だけを他のサービスとは独立して管理できるようになります。

他の例で AD-SUPPORT.pmod では、古い設定のActive Directoryとの互換性のため RC4などをKerberosだけで許可するため以下のようなサブポリシーを定義します。

cipher@kerberos = RC4-128+
hash@kerberos = MD5+

RHEL 8 と RHEL 9 でのssh サーバ実装の違い

すこし話が変わりますが、RHEL 8とRHEL 9では実装の違いがあります。ポリシー言語はそのままなのですが、sshサーバへ設定を反映させる方法が変わっています。 RHEL 8, 9 のどちらも問題なく動作するのですが、インプレースアップグレードを行うと問題が発生する場合があります。

RHEL 8の時にcrypto-policiesの設定を無視する設定をおこなった状態で、RHEL 9に更新すると、(8の時のまま動作してほしい期待に反して)crypto-policiesの設定に従った設定が利用されるので、意図しない動作の違いが発生します。インプレースアップグレードでなくても、設定の使いまわしができませんので注意が必要です。

RHEL 8とRHEL 9の実装の違いはこのようになっています。

RHEL 8では、sshd起動時のコマンドラインオプションとして crypto-policies が生成したポリシーを指定することで設定をおこなっていました。
RHEL 9では、設定のincludeにより、crypto-policiesが生成したポリシーを設定ファイルの一部として読み込み、コマンドラインの指定は行いません。

利用上の注意

/etc/crypto-policies/back-ends の直接編集はNG - このディレクトリ内のファイル update-crypto-policies コマンドの実行やパッケージの更新で上書きされます。特にデフォルトだとシンボリックリンクで /usr/share/crypto-policies/以下のファイルを指しており、管理者が直接編集することは想定されていません。間違えて編集してしまった場合は、 yum reinstall crypto-policies としてパッケージを再インストールすることで元にもどせます。

赤帽エンジニアブログ