手順

1. システム全体の暗号化ポリシーを LEGACY レベルに切り替えるには、root で以下のコマンドを実行します。

   # update-crypto-policies --set LEGACY
   Setting system policy to LEGACY

手順

1. RHEL Web コンソールにログインします。詳細は、Web コンソールへのログイン を参照してください。
2. Overview ページの Configuration カードで、Crypto policy の横にある現在のポリシー値をクリックします。
3. Change crypto policy ダイアログウィンドウで、使用を開始するポリシーレベルをクリックします。
4. Apply and reboot ボタンをクリックします。

手順

1. システムを FIPS モードに切り替えるには、以下のコマンドを実行します。

   # fips-mode-setup --enable
   Kernel initramdisks are being regenerated. This might take some time.
   Setting system policy to FIPS
   Note: System-wide crypto policies are applied on application start-up.
   It is recommended to restart the system for the change of policies
   to fully take place.
   FIPS mode will be enabled.
   Please reboot the system for the setting to take effect.

2. システムを再起動して、カーネルを FIPS モードに切り替えます。

   # reboot

検証

1. システムが再起動したら、FIPS モードの現在の状態を確認できます。

   # fips-mode-setup --check
   FIPS mode is enabled.

手順

1. /etc/crypto-policies/policies/modules/ ディレクトリーをチェックアウトします。

   # cd /etc/crypto-policies/policies/modules/

2. 調整用のサブポリシーを作成します。次に例を示します。

   # touch MYCRYPTO-1.pmod
   # touch SCOPES-AND-WILDCARDS.pmod

   重要

   ポリシーモジュールのファイル名には大文字を使用します。

3. 任意のテキストエディターでポリシーモジュールを開き、システム全体の暗号化ポリシーを変更するオプションを挿入します。次に例を示します。

   # vi MYCRYPTO-1.pmod

   min_rsa_size = 3072
   hash = SHA2-384 SHA2-512 SHA3-384 SHA3-512

   # vi SCOPES-AND-WILDCARDS.pmod

   # Disable the AES-128 cipher, all modes
   cipher = -AES-128-*
   
   # Disable CHACHA20-POLY1305 for the TLS protocol (OpenSSL, GnuTLS, NSS, and OpenJDK)
   cipher@TLS = -CHACHA20-POLY1305
   
   # Allow using the FFDHE-1024 group with the SSH protocol (libssh and OpenSSH)
   group@SSH = FFDHE-1024+
   
   # Disable all CBC mode ciphers for the SSH protocol (libssh and OpenSSH)
   cipher@SSH = -*-CBC
   
   # Allow the AES-256-CBC cipher in applications using libssh
   cipher@libssh = AES-256-CBC+

4. 変更をモジュールファイルに保存します。

5. ポリシーの調整を、システム全体の暗号化ポリシーレベル DEFAULT に適用します。

   # update-crypto-policies --set DEFAULT:MYCRYPTO-1:SCOPES-AND-WILDCARDS

6. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

   # reboot

手順

1. SHA1 サブポリシーを DEFAULT 暗号化ポリシーに適用します。

   # update-crypto-policies --set DEFAULT:SHA1
   Setting system policy to DEFAULT:SHA1
   Note: System-wide crypto policies are applied on application start-up.
   It is recommended to restart the system for the change of policies
   to fully take place.

2. システムを再起動します。

   # reboot

手順

1. カスタマイズのポリシーファイルを作成します。

   # cd /etc/crypto-policies/policies/
   # touch MYPOLICY.pol

   または、定義されている 4 つのポリシーレベルのいずれかをコピーします。

   # cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol

2. 必要に応じて、テキストエディターでファイルを編集します。以下のようにしてカスタム暗号化ポリシーを使用します。

   # vi /etc/crypto-policies/policies/MYPOLICY.pol

3. システム全体の暗号化ポリシーをカスタムレベルに切り替えます。

   # update-crypto-policies --set MYPOLICY

4. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

   # reboot

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   ---
   - hosts: all
     tasks:
     - name: Configure crypto policies
       include_role:
         name: rhel-system-roles.crypto_policies
       vars:
         - crypto_policies_policy: FUTURE
         - crypto_policies_reboot_ok: true

   FUTURE の値は、任意の暗号化ポリシー(例: DEFAULT、LEGACY、および FIPS:OSPP) に置き換えることができます。

   crypto_policies_reboot_ok: true 変数を設定すると、システムロールで暗号化ポリシーを変更した後にシステムが再起動されます。

   詳細については、crypto_policies システムロールの変数とファクト を参照してください。

2. オプション:Playbook の構文を確認します。

   # ansible-playbook --syntax-check playbook.yml

3. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file playbook.yml

検証

1. コントロールノードで (例: verify_playbook.yml) という名前の別の Playbook を作成します。

   - hosts: all
     tasks:
    - name: Verify active crypto policy
      include_role:
        name: rhel-system-roles.crypto_policies
   
    - debug:
        var: crypto_policies_active

   この Playbook では、システムの設定は変更されず、管理対象ノードのアクティブなポリシーだけを報告します。

2. 同じインベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file verify_playbook.yml
   
   TASK [debug] **************************
   ok: [host] => {
       "crypto_policies_active": "FUTURE"
   }

   "crypto_policies_active": 変数は、管理対象ノードでアクティブなポリシーを表示します。

手順

1. PKCS #11 の URI を含む OpenSC PKCS #11 モジュールが提供する鍵の一覧を表示し、その出力を keys.pub ファイルに保存します。

   $ ssh-keygen -D pkcs11: > keys.pub
   $ ssh-keygen -D pkcs11:
   ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
   ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

2. リモートサーバー (example.com) でスマートカードを使用した認証を有効にするには、公開鍵をリモートサーバーに転送します。前の手順で作成された keys.pub で ssh-copy-id コマンドを使用します。

   $ ssh-copy-id -f -i keys.pub username@example.com

3. 手順 1 の ssh-keygen -D コマンドの出力にある ECDSA 鍵を使用して example.com に接続するには、鍵を一意に参照する URI のサブセットのみを使用できます。以下に例を示します。

   $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com
   Enter PIN for 'SSH key':
   [example.com] $

4. ~/.ssh/config ファイルで同じ URI 文字列を使用して、設定を永続化できます。

   $ cat ~/.ssh/config
   IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
   $ ssh example.com
   Enter PIN for 'SSH key':
   [example.com] $

   OpenSSH は p11-kit-proxy ラッパーを使用し、OpenSC PKCS #11 モジュールが PKCS#11 キットに登録されているため、以前のコマンドを簡素化できます。

   $ ssh -i "pkcs11:id=%01" example.com
   Enter PIN for 'SSH key':
   [example.com] $

手順

1. /etc/polkit-1/rules.d/ ディレクトリーに新規ファイルを作成します。

   # touch /etc/polkit-1/rules.d/00-test.rules

2. 選択したエディターでファイルを編集します。以下に例を示します。

   # vi /etc/polkit-1/rules.d/00-test.rules

3. 以下の行を挿入します。

   polkit.addRule(function(action, subject) {
     if (action.id == "org.debian.pcsc-lite.access_pcsc" ||
     	action.id == "org.debian.pcsc-lite.access_card") {
   	polkit.log("action=" + action);
   	polkit.log("subject=" + subject);
     }
   });

   ファイルを保存して、エディターを終了します。

4. pcscd サービスおよび polkit サービスを再起動します。

   # systemctl restart pcscd.service pcscd.socket polkit.service

検証

1. pcscd の認可リクエストを作成します。たとえば、Firefox の Web ブラウザーを開くか、opensc が提供する pkcs11-tool -L を使用します。

2. 拡張ログエントリーを表示します。以下に例を示します。

   # journalctl -u polkit --since "1 hour ago"
   polkitd[1224]: <no filename>:4: action=[Action id='org.debian.pcsc-lite.access_pcsc']
   polkitd[1224]: <no filename>:5: subject=[Subject pid=2020481 user=user' groups=user,wheel,mock,wireshark seat=null session=null local=true active=true]

手順

1. oscap コマンドに --remediate オプションを指定して使用します。

   # oscap xccdf eval --profile hipaa --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. システムを再起動します。

検証

1. システムの OSPP プロファイルへのコンプライアンスを評価し、スキャン結果を ospp_report.html ファイルに保存します。

   $ oscap xccdf eval --report hipaa_report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

手順

1. Ansible を使用して OSPP に合わせてシステムを修正します。

   # ansible-playbook -i localhost, -c local /usr/share/scap-security-guide/ansible/rhel9-playbook-hipaa.yml

2. システムを再起動します。

検証

1. システムの OSPP プロファイルへのコンプライアンスを評価し、スキャン結果を ospp_report.html ファイルに保存します。

   # oscap xccdf eval --profile hipaa --report hipaa_report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

手順

1. システムをスキャンして結果を保存します。

   # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. 前の手順で生成されたファイルに基づいて Ansible Playbook を生成します。

   # oscap xccdf generate fix --fix-type ansible --profile hipaa --output hipaa-remediations.yml hipaa-results.xml

3. hippa-remediations.yml ファイルには、手順 1 で実行されたスキャン中に失敗したルールの Ansible 修復が含まれています。この生成されたファイルを確認した後、ansible-playbook hipaa-remediations.yml コマンドで適用できます。

手順

1. oscap コマンドを使用してシステムをスキャンし、結果を XML ファイルに保存します。以下の例では、oscap は hipaa プロファイルに対してシステムを評価します。

   # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. 前の手順で生成された結果ファイルに基づいて Bash スクリプトを生成します。

   # oscap xccdf generate fix --profile hipaa --fix-type bash --output hipaa-remediations.sh hipaa-results.xml

3. hippa-dss-remediations.sh ファイルには、手順 1 で実行されたスキャン中に失敗したルールの修復が含まれます。この生成されたファイルを確認したら、このファイルと同じディレクトリー内で ./hipaa-remediations.sh コマンドを使用して適用できます。

手順

1. システムに最新 RHSA OVAL 定義をダウンロードします。

   # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2 | bzip2 --decompress > rhel-9.oval.xml

2. コンテナーまたはコンテナーイメージの ID を取得します。以下に例を示します。

   # podman images
   REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
   registry.access.redhat.com/ubi9/ubi   latest   096cae65a207   7 weeks ago   239 MB

3. コンテナーまたはコンテナーイメージで脆弱性をスキャンし、結果を vulnerability.html ファイルに保存します。

   # oscap-podman 096cae65a207 oval eval --report vulnerability.html rhel-9.oval.xml

   oscap-podman コマンドには root 権限が必要で、コンテナーの ID は最初の引数であることに注意してください。

手順

1. コンテナーまたはコンテナーイメージの ID を取得します。以下に例を示します。

   # podman images
   REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
   registry.access.redhat.com/ubi9/ubi   latest   096cae65a207   7 weeks ago   239 MB

2. HIPAA プロファイルでコンテナーイメージのコンプライアンスを評価し、スキャン結果を report.html ファイルに保存します。

   # oscap-podman 096cae65a207 xccdf eval --report report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

   OSPP または PCI-DSS ベースラインでセキュリティーコンプライアンスを評価する場合は、096cae65a207 をコンテナーイメージの ID に、hipaa の値を ospp または pci-dss に置き換えます。oscap-podman コマンドには、root 権限が必要なことに注意してください。

手順

1. 必要な Keylim コンポーネントをインストールします。verifier と registrar は、要件に応じて、1 つのシステムまたは 2 つの別個のシステムにインストールできます。

   • Keylime のすべてのコンポーネントをインストールするには、以下を実行します。

     # dnf install keylime

   • Keylime 検証ツールのみをインストールするには、以下を実行します。

     # dnf install keylime-verifier

   • Keylime レジストラのみをインストールするには、以下を実行します。

     # dnf install keylime-registrar

2. verifier と registrar を別々のシステムにインストールする場合は、verifier 設定で registrar の IP アドレスとポートを定義します。verifier がインストールされているシステムで、/etc/keylime/verifier.conf.d/ ディレクトリーに新しい .conf ファイルを作成します (例: /etc/keylime/verifier.conf.d/00-registrar-ip.conf の内容は次のとおりです)。

   [verifier]
   
   registrar_ip = <registrar_IP_address>

   • <registrar_IP_address> を registrar の IP アドレスに置き換えます。
   • オプションで、registrar_port = <registrar_port> オプションを使用して、registrar のポートをデフォルト値の 8891 から変更することもできます。

3. オプション:エージェントのリスト用に verifier のデータベースを設定します。デフォルトの設定では、verifier の /var/lib/keylime/cv_data.sqlite ディレクトリーにある SQLite データベースを使用します。/etc/keylime/verifier.conf.d/ ディレクトリーに新しい .conf ファイルを作成することで、別のデータベースを定義できます (例: /etc/keylime/verifier.conf.d/00-db-ip.conf の内容は次のとおりです)。

   [verifier]
   # Database URL Configuration
   database_url = <database_url>

   <database_url> をデータベースの URL に置き換えます。

4. verifier に証明書とキーを追加します。verifier には、次のキーと証明書が必要です。

   • server_key
   • server_cert
   • client_key
   • client_cert

   • trusted_client_ca

     • テナントクライアント CA 証明書へのパス

   • trusted_server_ca

     • registrar サーバー CA 証明書へのパス
   1. デフォルトの設定を使用して、キーと証明書を /var/lib/keylime/cv_ca ディレクトリーにロードできます。

   2. または、設定でキーと証明書の場所を定義することもできます。/etc/keylime/verifier.conf.d/ ディレクトリーに新しい .conf ファイルを作成します。たとえば、/etc/keylime/verifier.conf.d/00-keys-and-certs.conf のように、次の内容で作成します。

      [verifier]
      tls_dir = default
      server_key = </path/to/server_key>
      server_key_password = <passphrase1>
      server_cert = </path/to/server_cert>
      trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']
      client_key = </path/to/client_key>
      client_key_password = <passphrase2>
      client_cert = </path/to/client_cert>
      trusted_server_ca = ['</path/to/ca/cert3>', '</path/to/ca/cert4>']

      注記

      絶対パスを使用して、キーと証明書の場所を定義します。または、tls_dir オプションでディレクトリーを定義し、そのディレクトリーからの相対パスを使用することもできます。

5. オプション:エージェントのリスト用に registrar のデータベースを設定します。デフォルト設定では、registrar の /var/lib/keylime/reg_data.sqlite ディレクトリーにある SQLite データベースを使用します。/etc/keylime/registrar.conf.d/ ディレクトリーに新しい .conf ファイルを作成できます (例: /etc/keylime/registrar.conf.d/00-db-ip.conf の内容は次のとおりです)。

   [registrar]
   # Database URL Configuration
   database_url = <database_url>

   <database_url> をデータベースの URL に置き換えます。

6. registrar に証明書とキーを追加します。registrar には、次のキーと証明書が必要です。

   • server_key
   • server_cert

   • trusted_client_ca

     • verifier クライアント CA 証明書へのパス
     • テナントクライアント CA 証明書へのパス
   1. デフォルトの設定を使用して、キーと証明書を /var/lib/keylime/reg_ca ディレクトリーにロードできます。

   2. または、設定でキーと証明書の場所を定義することもできます。/etc/keylime/registrar.conf.d/ ディレクトリーに新しい .conf ファイルを作成します (例: /etc/keylime/registrar.conf.d/00-keys-and-certs.conf の内容は次のとおりです)。

      [registrar]
      tls_dir = default
      server_key = </path/to/server_key>
      server_key_password = <passphrase1>
      server_cert = </path/to/server_cert>
      trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']

      注記

      絶対パスを使用して、キーと証明書の場所を定義します。または、tls_dir オプションでディレクトリーを定義し、そのディレクトリーからの相対パスを使用することもできます。

7. verifier サービスを開始します。

   注記

   設定ファイルを正しい順序でロードできるように、registrar を開始する前に verifier を開始します。Keylime を停止する必要がある場合は、逆の順序でサービスを停止します。

   $ systemctl start keylime_verifier

8. registrar サービスを開始します。

   $ systemctl start keylime_registrar

検証

1. Keylime サービスのステータスを確認します。

   $ systemctl status keylime_verifier
   ● keylime_verifier.service - The Keylime verifier
        Loaded: loaded (/usr/lib/systemd/system/keylime_verifier.service; disabled; vendor preset: disabled)
        Active: active (running) since Wed 2022-11-09 10:10:08 EST; 1min 45s ago
   ...
   $ systemctl status keylime_registrar
   ● keylime_registrar.service - The Keylime registrar service
        Loaded: loaded (/usr/lib/systemd/system/keylime_registrar.service; disabled; vendor preset: disabled)
        Active: active (running) since Wed 2022-11-09 10:10:17 EST; 1min 42s ago
   ...

2. verifier のステータスを確認します。

   $ keylime_tenant -c cvstatus
   Reading configuration from ['/etc/keylime/logging.conf']
   2022-10-14 12:56:08.155 - keylime.tpm - INFO - TPM2-TOOLS Version: 5.2
   Reading configuration from ['/etc/keylime/tenant.conf']
   2022-10-14 12:56:08.157 - keylime.tenant - INFO - Setting up client TLS...
   2022-10-14 12:56:08.158 - keylime.tenant - INFO - Using default client_cert option for tenant
   2022-10-14 12:56:08.158 - keylime.tenant - INFO - Using default client_key option for tenant
   2022-10-14 12:56:08.178 - keylime.tenant - INFO - TLS is enabled.
   2022-10-14 12:56:08.178 - keylime.tenant - WARNING - Using default UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000
   2022-10-14 12:56:08.221 - keylime.tenant - INFO - Verifier at 127.0.0.1 with Port 8881 does not have agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000.

   正しくセットアップされていて、エージェントが設定されていない場合、verifier はエージェント UUID を認識しません。

3. registrar のステータスを確認します。

   $ keylime_tenant -c regstatus
   Reading configuration from ['/etc/keylime/logging.conf']
   2022-10-14 12:56:02.114 - keylime.tpm - INFO - TPM2-TOOLS Version: 5.2
   Reading configuration from ['/etc/keylime/tenant.conf']
   2022-10-14 12:56:02.116 - keylime.tenant - INFO - Setting up client TLS...
   2022-10-14 12:56:02.116 - keylime.tenant - INFO - Using default client_cert option for tenant
   2022-10-14 12:56:02.116 - keylime.tenant - INFO - Using default client_key option for tenant
   2022-10-14 12:56:02.137 - keylime.tenant - INFO - TLS is enabled.
   2022-10-14 12:56:02.137 - keylime.tenant - WARNING - Using default UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000
   2022-10-14 12:56:02.171 - keylime.registrar_client - CRITICAL - Error: could not get agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 data from Registrar Server: 404
   2022-10-14 12:56:02.172 - keylime.registrar_client - CRITICAL - Response code 404: agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 not found
   2022-10-14 12:56:02.172 - keylime.tenant - INFO - Agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 does not exist on the registrar. Please register the agent with the registrar.
   2022-10-14 12:56:02.172 - keylime.tenant - INFO - {"code": 404, "status": "Agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 does not exist on registrar 127.0.0.1 port 8891.", "results": {}}

   正しくセットアップされていて、エージェントが設定されていない場合、registrar はエージェント UUID を認識しません。

手順

1. 監視するシステムに Keylime エージェントをインストールします。

   # dnf install keylime-agent

   このコマンドは、keylime-agent-rust パッケージをインストールします。

2. 設定ファイルでレジストラの IP アドレスとポートを定義します。/etc/keylime/agent.conf.d/ ディレクトリーに新しい .conf ファイルを作成します (例: /etc/keylime/agent.conf.d/00-registrar-ip.conf の内容は次のとおりです)。

   [agent]
   
   registrar_ip = "<registrar_IP_address>"

   • <registrar_IP_address> を registrar の IP アドレスに置き換えます。

   • オプションで、registrar_port = <registrar_port> オプションを使用して、registrar のポートをデフォルト値の 8890 から変更することもできます。

     注記

     Keylime エージェントの設定は、他のコンポーネントの設定に使用される INI 形式とは異なる TOML 形式を使用するため、IP アドレスは引用符で囲む必要があります。

3. オプション:エージェントの既存の鍵と証明書をロードします。エージェントが server_key と server_cert を受信しない場合、エージェントは独自のキーと自己署名証明書を生成します。エージェントは、次のキーと証明書を受け入れます。

   • server_key (オプション)
   • server_cert (オプション)

   • trusted_client_ca

     • verifier クライアント CA 証明書へのパス
     • テナントクライアント CA 証明書へのパス

   設定でキーと証明書の場所を定義します。/etc/keylime/agent.conf.d/ ディレクトリーに新しい .conf ファイルを作成します (例: /etc/keylime/agent.conf.d/00-keys-and-certs.conf は、次の内容を記述します)。

   [agent]
   server_key = </path/to/server_key>
   server_key_password = <passphrase1>
   server_cert = </path/to/server_cert>
   trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']
   enc_keyname = </path/to/derived_cti_key>

   注記

   絶対パスを使用して、キーと証明書の場所を定義します。Keylim エージェントは相対パスを受け入れません。

4. システムの現在の状態の測定されたブートログからポリシーを生成します。

   注意

   一部のシナリオでは、Keylime 測定ブートポリシー生成スクリプトがセグメンテーションエラーとコアダンプを引き起こす可能性があります。詳細は、RHBZ#2140670 を参照してください。

   $ /usr/share/keylime/scripts/create_mb_refstate /sys/kernel/security/tpm0/binary_bios_measurements <./measured_boot_reference_state.json>

   <./measured_boot_reference_state.json> を、スクリプトが生成されたポリシーを保存するパスに置き換えます。

   重要

   create_mb_refstate スクリプトで生成されるポリシーは、システムの現在の状態に基づいており、非常に厳格です。カーネルの更新やシステムの更新を含むシステムの変更は、ブートプロセスを変更し、システムは認証に失敗します。

5. オプション:Keylime 測定から除外するファイルとディレクトリーのリストを定義するには、<excludelist> などの名前のファイルを作成し、除外するファイルとディレクトリーを入力します。除外リストは、Python の正規表現を受け入れます。詳細は、docs.python.org の正規表現の操作 を参照してください。たとえば、/tmp/ ディレクトリー内のすべてのファイルを除外するには、次のようにします。

   /tmp/.*

6. keylime_tenant ユーティリティーを使用して新しいエージェントをプロビジョニングします。ネットワークに接続され、正しいキーと証明書が提供されている任意のシステムからエージェントをプロビジョニングできます。

   $ keylime_tenant -c add -t <agent.ip> -v <verifier.ip> -u <agent-uuid> --mb_refstate <./measured_boot_reference_state.json> --exclude <excludelist> -f <filetosend>

   • <agent.ip> をエージェントの IP アドレスに置き換えます。
   • <verifier.ip> を verifier の IP アドレスに置き換えます。
   • <agent-uuid> をエージェントの UUID に置き換えます。
   • <./measured_boot_reference_state.json> を、測定されたブートポリシーへのパスに置き換えます。
   • <excludelist> を除外リストファイルへのパスに置き換えます。--exclude オプションはオプションです。エージェントのプロビジョニングは、ファイルを配信しなくても機能します。
   • <filetosend> を、エージェントに配信されるファイルへのパスに置き換えます。-f オプションはオプションです。エージェントのプロビジョニングは、ファイルを配信しなくても機能します。
   注記

   Keylime はエージェントに送信されたファイルを暗号化し、エージェントのシステムが TPM ポリシーと IMA 許可リストに準拠している場合にのみ復号化します。デフォルトでは、Keylime は .zip ファイルを解凍します。また、payload_script = "autorun.sh" オプションを使用して、ファイルが復号化された後に実行するスクリプトを指定することもできます。

   例として、次のコマンドを使用すると、keylime_tenant は 127.0.0.1 で UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000 で新しい Keylime エージェントをプロビジョニングし、それを 127.0.0.2 で verifier に接続します。また、payload1 という名前のファイルを暗号化し、エージェントに送信します。Keylime は、エージェントのシステムが TPM ポリシーと IMA 許可リストに準拠している場合にのみ、ファイルを復号します。

   $ keylime_tenant -c add -t 127.0.0.1 -v 127.0.0.2 -u d432fbb3-d2f1-4a97-9ef7-75bd81c00000 -f payload1

7. keylime_agent サービスを開始します。

   $ systemctl start keylime_agent

   注記

   正しいキーと証明書を使用して、ネットワーク内の任意のシステムから次のコマンドを使用して、Keylime によるノードの監視を停止できます。

   $ keylime_tenant -c delete -t <agent.ip> -u <agent.uuid>

検証

1. registrar に登録されているすべてのエージェントの UUID を一覧表示します。

   $ keylime_tenant -c reglist -r <registrar_IP_address> -rp <registrar_port>
   2022-10-07 13:52:54.388 - keylime.tenant - INFO - From registrar 127.0.0.1 port 8891 retrieved {"code": 200, "status": "Success", "results": {"uuids": ["d432fbb3-d2f1-4a97-9ef7-75bd81c00000"]}}

   • <registrar_IP_address> を registrar の IP アドレスに置き換えます。
   • オプションで、registrar_port = <registrar_port> オプションを使用して、registrar のポートをデフォルト値の 8891 から変更することもできます。
   注記

   エージェントを繰り返し一覧表示する必要がある場合は、/etc/keylime/tenant.conf.d/ ディレクトリーの設定スニペットで registrar の IP アドレスとポートを定義できます。その後、-r および -rp オプションなしでコマンドを入力できます。

2. verifier のステータスを確認します。

   $ keylime_tenant -c cvstatus
   Reading configuration from ['/etc/keylime/logging.conf']
   ...
   {"d432fbb3-d2f1-4a97-9ef7-75bd81c00000": {"operational_state": "Get Quote", "v": "rMUdRQtojhtoufQGLS5mur9yrH7ZDhivxAVihhMlLTc=", "ip": "127.0.0.1", "port": 9002, "tpm_policy": "{\"mask\": \"0x0\"}", "meta_data": "{\"cert_serial\": 2, \"subject\": \"OU=53,O=MITLL,L=Lexington,ST=MA,CN=d432fbb3-d2f1-4a97-9ef7-75bd81c00000,C=US\"}", "allowlist_len": 6, "mb_refstate_len": 0, "accept_tpm_hash_algs": ["sha512", "sha384", "sha256", "sha1"], "accept_tpm_encryption_algs": ["ecc", "rsa"], "accept_tpm_signing_algs": ["ecschnorr", "rsassa"], "hash_alg": "sha256", "enc_alg": "rsa", "sign_alg": "rsassa", "verifier_id": "default", "verifier_ip": "127.0.0.1", "verifier_port": 8881, "severity_level": null, "last_event_id": null, "attestation_count": 7, "last_received_quote": 1665753341}}

   verifier と agent が正しく設定されている場合、出力には正しいエージェント UUID が表示され、その後に {"operational_state":"Get Quote” が表示されます。

3. registrar のステータスを確認します。

   $ keylime_tenant -c regstatus
   Reading configuration from ['/etc/keylime/logging.conf']
   ...
   ==\n-----END CERTIFICATE-----\n", "ip": "127.0.0.1", "port": 9002, "regcount": 1, "operational_state": "Registered"}}}

   registrar と agent が正しく設定されている場合、出力にはエージェントの IP アドレスとポートが表示され、その後に "operational_state":"Registered" が表示されます。

手順

1. 監視対象のシステムに Keylime エージェントをインストールします。

   # dnf install keylime-agent

   このコマンドは、keylime-agent-rust パッケージをインストールします。

2. /etc/ima/ima-policy ファイルに次の内容を入力して、新しい IMA ポリシーを作成します。

   # PROC_SUPER_MAGIC
   dont_measure fsmagic=0x9fa0
   # SYSFS_MAGIC
   dont_measure fsmagic=0x62656572
   # DEBUGFS_MAGIC
   dont_measure fsmagic=0x64626720
   # TMPFS_MAGIC
   dont_measure fsmagic=0x01021994
   # RAMFS_MAGIC
   dont_measure fsmagic=0x858458f6
   # SECURITYFS_MAGIC
   dont_measure fsmagic=0x73636673
   # SELINUX_MAGIC
   dont_measure fsmagic=0xf97cff8c
   # CGROUP_SUPER_MAGIC
   dont_measure fsmagic=0x27e0eb
   # OVERLAYFS_MAGIC
   dont_measure fsmagic=0x794c7630
   # Don't measure log, audit or tmp files
   dont_measure obj_type=var_log_t
   dont_measure obj_type=auditd_log_t
   dont_measure obj_type=tmp_t
   # MEASUREMENTS
   measure func=BPRM_CHECK
   measure func=FILE_MMAP mask=MAY_EXEC
   measure func=MODULE_CHECK uid=0

3. デフォルトの IMA ポリシーを新しい IMA ポリシーに置き換えます。

   # cat /etc/ima/ima-policy > /sys/kernel/security/ima/policy

4. システムを再起動して、新しい IMA ポリシーを適用します。

5. システムの現在の状態から許可リストを生成します。

   # /usr/share/keylime/scripts/create_allowlist.sh -o <allowlist.txt> -h sha256sum

   <allowlist.txt> を許可リストのファイル名に置き換えます。

   重要

   SHA-256 ハッシュ関数を使用します。SHA-1 は安全ではなく、RHEL 9 で廃止されました。追加情報は、SHA-1 deprecation in Red Hat Enterprise Linux 9 を参照してください。

6. 設定ファイルでレジストラの IP アドレスとポートを定義します。/etc/keylime/agent.conf.d/ ディレクトリーに新しい .conf ファイルを作成します (例: /etc/keylime/agent.conf.d/00-registrar-ip.conf の内容は次のとおりです)。

   [agent]
   
   registrar_ip = "<registrar_IP_address>"

   • <registrar_IP_address> を registrar の IP アドレスに置き換えます。

   • オプションで、registrar_port = <registrar_port> オプションを使用して、registrar のポートをデフォルト値の 8890 から変更することもできます。

     注記

     Keylime エージェントの設定は、他のコンポーネントの設定に使用される INI 形式とは異なる TOML 形式を使用するため、IP アドレスは引用符で囲む必要があります。

7. オプション:エージェントの既存の鍵と証明書をロードします。エージェントが server_key と server_cert を受信しない場合、エージェントは独自のキーと自己署名証明書を生成します。エージェントは、次のキーと証明書を受け入れます。

   • server_key (オプション)
   • server_cert (オプション)

   • trusted_client_ca

     • verifier クライアント CA 証明書へのパス
     • テナントクライアント CA 証明書へのパス

   設定でキーと証明書の場所を定義します。/etc/keylime/agent.conf.d/ ディレクトリーに新しい .conf ファイルを作成します (例: /etc/keylime/agent.conf.d/00-keys-and-certs.conf は、次の内容を記述します)。

   [agent]
   server_key = </path/to/server_key>
   server_key_password = <passphrase1>
   server_cert = </path/to/server_cert>
   trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']
   enc_keyname = </path/to/derived_cti_key>

   注記

   絶対パスを使用して、キーと証明書の場所を定義します。Keylim エージェントは相対パスを受け入れません。

8. オプション:<excludelist> などの名前のファイルを作成し、除外するファイルとディレクトリーを入力することで、Keylime 測定から除外するファイルまたはディレクトリーのリストを定義できます。除外リストは、Python の正規表現を受け入れます。詳細は、docs.python.org の正規表現の操作 を参照してください。たとえば、/tmp/ ディレクトリー内のすべてのファイルを除外するには、次のように入力します。

   /tmp/.*

9. keylime_tenant ユーティリティーを使用して新しいエージェントをプロビジョニングします。ネットワークに接続され、正しいキーと証明書が提供されている任意のシステムからエージェントをプロビジョニングできます。

   $ keylime_tenant -c add -t <agent.ip> -v _<verifier.ip> -u _<agent.uuid> --allowlist _<allowlist.txt> --exclude <excludelist> -f _<filetosend>

   • <agent.ip> をエージェントの IP アドレスに置き換えます。
   • <verifier.ip> を verifier の IP アドレスに置き換えます。
   • <agent.uuid> をエージェントの UUID に置き換えます。
   • <allowlist.txt> を許可リストファイルへのパスに置き換えます。
   • <excludelist> を除外リストファイルへのパスに置き換えます。--exclude オプションはオプションです。エージェントのプロビジョニングは、ファイルを配信しなくても機能します。
   • <filetosend> を、エージェントに配信されるファイルへのパスに置き換えます。-f オプションはオプションです。エージェントのプロビジョニングは、ファイルを配信しなくても機能します。
   注記

   Keylime はエージェントに送信されたファイルを暗号化し、エージェントのシステムが TPM ポリシーと IMA 許可リストに準拠している場合にのみ復号化します。デフォルトでは、Keylime は .zip ファイルを解凍します。また、payload_script = "autorun.sh" オプションを使用して、ファイルが復号化された後に実行するスクリプトを指定することもできます。

   例として、次のコマンドを使用すると、keylime_tenant は 127.0.0.1 に UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000 で新しい Keylime エージェントをプロビジョニングし、それを 127.0.0.2 の verifier に接続して、allowlist1.txt という名前の許可リストを読み込みます。また、payload1 という名前のファイルを暗号化し、エージェントに送信します。Keylime は、/etc/keylime/verifier.conf で設定された TPM ポリシーが満たされている場合にのみ、ファイルを復号化します。

   $ keylime_tenant -c add -t 127.0.0.1 -v 127.0.0.2 -u d432fbb3-d2f1-4a97-9ef7-75bd81c00000 -f payload1 --allowlist allowlist1.txt

10. keylime_agent サービスを開始します。

    $ systemctl start keylime_agent

    注記

    正しいキーと証明書を使用して、ネットワーク内の任意のシステムから次のコマンドを使用して、Keylime によるノードの監視を停止できます。

    $ keylime_tenant -c delete -t <agent.ip> -u <agent.uuid>

検証

1. たとえば、bad-script.sh という名前の新しいファイルを作成し、許可リストで許可されていないアクションを実行する次のコンテンツを挿入します。

   #!/bin/sh
   
   echo -e "Hello Evil!"

2. スクリプトを実行可能にします。

   # chmod +x bad-script.sh

3. スクリプトの実行を試みます。許可リストが正しく設定されている場合は、このエージェントの Keylime 設定証明は失敗し、同様の出力が表示されます。

   # ./bad-script.sh
   keylime.tpm - INFO - Checking IMA measurement list...
   keylime.ima - WARNING - File not found in allowlist: /root/bad-script.sh
   keylime.ima - ERROR - IMA ERRORS: template-hash 0 fnf 1 hash 0 good 781
   keylime.cloudverifier - WARNING - agent D432FBB3-D2F1-4A97-9EF7-75BD81C00000 failed, stopping polling

手順

1. aide パッケージをインストールするには、次のコマンドを実行します。

   # dnf install aide

2. 初期データベースを生成するには、次のコマンドを実行します。

   # aide --init

   注記

   デフォルト設定では、aide --init コマンドは、/etc/aide.conf ファイルで定義するディレクトリーとファイルのセットのみを確認します。ディレクトリーまたはファイルを AIDE データベースに追加し、監視パラメーターを変更するには、/etc/aide.conf を変更します。

3. データベースの使用を開始するには、初期データベースのファイル名から末尾の .new を削除します。

   # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

4. AIDE データベースの場所を変更するには、/etc/aide.conf ファイルを編集して、DBDIR 値を変更します。追加のセキュリティーのデータベース、設定、/usr/sbin/aide バイナリーファイルを、読み取り専用メディアなどの安全な場所に保存します。

手順

1. 手動でチェックを開始するには、以下を行います。

   # aide --check
   Start timestamp: 2018-07-11 12:41:20 +0200 (AIDE 0.16)
   AIDE found differences between database and filesystem!!
   ...
   [trimmed for clarity]

2. 最低でも、AIDE は週ごとに実行するようにシステムを設定します。最適な設定としては、AIDE を毎日実行します。たとえば、AIDE を毎日午前 04:05 に実行するようにスケジュールするには、cron コマンドを使用して、次の行を /etc/crontab ファイルを追加します。

    05 4 * * * root /usr/sbin/aide --check

手順

1. 基本となる AIDE データベースを更新します。

   # aide --update

   aide --update コマンドは、/var/lib/aide/aide.db.new.gz データベースファイルを作成します。

2. 整合性チェックで更新したデータベースを使用するには、ファイル名から末尾の .new を削除します。

手順

1. 暗号化するデバイスにあるファイルシステムのマウントをすべて解除します。次に例を示します。

   # umount /dev/mapper/vg00-lv00

2. LUKS ヘッダーを保存するための空き容量を確認します。シナリオに合わせて、次のいずれかのオプションを使用します。

   • 論理ボリュームを暗号化する場合は、以下のように、ファイルシステムのサイズを変更せずに、論理ボリュームを拡張できます。以下はその例です。

     # lvextend -L+32M /dev/mapper/vg00-lv00

   • parted などのパーティション管理ツールを使用してパーティションを拡張します。
   • このデバイスのファイルシステムを縮小します。ext2、ext3、または ext4 のファイルシステムには resize2fs ユーティリティーを使用できます。XFS ファイルシステムは縮小できないことに注意してください。

3. 暗号化を初期化します。

   # cryptsetup reencrypt --encrypt --init-only --reduce-device-size 32M /dev/mapper/vg00-lv00 lv00_encrypted
   
   /dev/mapper/lv00_encrypted is now active and ready for online encryption.

4. デバイスをマウントします。

   # mount /dev/mapper/lv00_encrypted /mnt/lv00_encrypted

5. 永続的なマッピングのエントリーを /etc/crypttab ファイルに追加します。

   1. luksUUID を見つけます。

      # cryptsetup luksUUID /dev/mapper/vg00-lv00
      
      a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325

   2. 任意のテキストエディターで /etc/crypttab を開き、このファイルにデバイスを追加します。

      $ vi /etc/crypttab
      
      lv00_encrypted UUID=a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325 none

      a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325 は、デバイスの luksUUID に置き換えます。

   3. dracut で initramfs を更新します。

      $ dracut -f --regenerate-all

6. /etc/fstab ファイルに永続的なマウントのエントリーを追加します。

   1. アクティブな LUKS ブロックデバイスのファイルシステムの UUID を見つけます。

      $ blkid -p /dev/mapper/lv00_encrypted
      
      /dev/mapper/lv00-encrypted: UUID="37bc2492-d8fa-4969-9d9b-bb64d3685aa9" BLOCK_SIZE="4096" TYPE="xfs" USAGE="filesystem"

   2. 任意のテキストエディターで /etc/fstab を開き、このファイルにデバイスを追加します。次に例を示します。

      $ vi /etc/fstab
      
      UUID=37bc2492-d8fa-4969-9d9b-bb64d3685aa9 /home auto rw,user,auto 0

      37bc2492-d8fa-4969-9d9b-bb64d3685aa9 は、ファイルシステムの UUID に置き換えます。

7. オンライン暗号化を再開します。

   # cryptsetup reencrypt --resume-only /dev/mapper/vg00-lv00
   
   Enter passphrase for /dev/mapper/vg00-lv00:
   Auto-detected active dm device 'lv00_encrypted' for data device /dev/mapper/vg00-lv00.
   Finished, time 00:31.130, 10272 MiB written, speed 330.0 MiB/s

検証

1. 既存のデータが暗号化されているかどうかを確認します。

   # cryptsetup luksDump /dev/mapper/vg00-lv00
   
   LUKS header information
   Version: 2
   Epoch: 4
   Metadata area: 16384 [bytes]
   Keyslots area: 16744448 [bytes]
   UUID: a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325
   Label: (no label)
   Subsystem: (no subsystem)
   Flags: (no flags)
   
   Data segments:
     0: crypt
   	offset: 33554432 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   [...]

2. 暗号化された空のブロックデバイスのステータスを表示します。

   # cryptsetup status lv00_encrypted
   
   /dev/mapper/lv00_encrypted is active and is in use.
     type:    LUKS2
     cipher:  aes-xts-plain64
     keysize: 512 bits
     key location: keyring
     device:  /dev/mapper/vg00-lv00

手順

1. 以下のように、そのデバイスのファイルシステムをすべてアンマウントします。

   # umount /dev/nvme0n1p1

2. 暗号化を初期化します。

   # cryptsetup reencrypt --encrypt --init-only --header /home/header /dev/nvme0n1p1 nvme_encrypted
   
   WARNING!
   ========
   Header file does not exist, do you want to create it?
   
   Are you sure? (Type 'yes' in capital letters): YES
   Enter passphrase for /home/header:
   Verify passphrase:
   /dev/mapper/nvme_encrypted is now active and ready for online encryption.

   /home/header は、独立した LUKS ヘッダーを持つファイルへのパスに置き換えます。後で暗号化したデバイスのロックを解除するために、独立した LUKS ヘッダーにアクセスできる必要があります。

3. デバイスをマウントします。

   # mount /dev/mapper/nvme_encrypted /mnt/nvme_encrypted

4. オンライン暗号化を再開します。

   # cryptsetup reencrypt --resume-only --header /home/header /dev/nvme0n1p1
   
   Enter passphrase for /dev/nvme0n1p1:
   Auto-detected active dm device 'nvme_encrypted' for data device /dev/nvme0n1p1.
   Finished, time 00m51s,   10 GiB written, speed 198.2 MiB/s

検証

1. 独立したヘッダーがある LUKS2 を使用するブロックデバイスの既存のデータが暗号化されているかどうかを確認します。

   # cryptsetup luksDump /home/header
   
   LUKS header information
   Version:       	2
   Epoch:         	88
   Metadata area: 	16384 [bytes]
   Keyslots area: 	16744448 [bytes]
   UUID:          	c4f5d274-f4c0-41e3-ac36-22a917ab0386
   Label:         	(no label)
   Subsystem:     	(no subsystem)
   Flags:       	(no flags)
   
   Data segments:
     0: crypt
   	offset: 0 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   	sector: 512 [bytes]
   [...]

2. 暗号化された空のブロックデバイスのステータスを表示します。

   # cryptsetup status nvme_encrypted
   
   /dev/mapper/nvme_encrypted is active and is in use.
     type:    LUKS2
     cipher:  aes-xts-plain64
     keysize: 512 bits
     key location: keyring
     device:  /dev/nvme0n1p1

手順

1. 暗号化した LUKS パーティションとしてパーティションを設定します。

   # cryptsetup luksFormat /dev/nvme0n1p1
   
   WARNING!
   ========
   This will overwrite data on /dev/nvme0n1p1 irrevocably.
   Are you sure? (Type 'yes' in capital letters): YES
   Enter passphrase for /dev/nvme0n1p1:
   Verify passphrase:

2. 暗号化した LUKS パーティションを開きます。

   # cryptsetup open dev/nvme0n1p1 nvme0n1p1_encrypted
   
   Enter passphrase for /dev/nvme0n1p1:

   これにより、パーティションのロックが解除され、デバイスマッパーを使用してパーティションが新しいデバイスにマッピングされます。暗号化されたデータを上書きしないように、このコマンドは、デバイスが暗号化されたデバイスであり、/dev/mapper/device_mapped_name パスを使用して LUKS を通じてアドレス指定されることをカーネルに警告します。

3. 暗号化されたデータをパーティションに書き込むためのファイルシステムを作成します。このパーティションには、デバイスマップ名を介してアクセスする必要があります。

   # mkfs -t ext4 /dev/mapper/nvme0n1p1_encrypted

4. デバイスをマウントします。

   # mount /dev/mapper/nvme0n1p1_encrypted mount-point

検証

1. 空のブロックデバイスが暗号化されているかどうかを確認します。

   # cryptsetup luksDump /dev/nvme0n1p1
   
   LUKS header information
   Version:       	2
   Epoch:         	3
   Metadata area: 	16384 [bytes]
   Keyslots area: 	16744448 [bytes]
   UUID:          	34ce4870-ffdf-467c-9a9e-345a53ed8a25
   Label:         	(no label)
   Subsystem:     	(no subsystem)
   Flags:       	(no flags)
   
   Data segments:
     0: crypt
   	offset: 16777216 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   	sector: 512 [bytes]
   [...]

2. 暗号化された空のブロックデバイスのステータスを表示します。

   # cryptsetup status nvme0n1p1_encrypted
   
   /dev/mapper/nvme0n1p1_encrypted is active and is in use.
     type:    LUKS2
     cipher:  aes-xts-plain64
     keysize: 512 bits
     key location: keyring
     device:  /dev/nvme0n1p1
     sector size:  512
     offset:  32768 sectors
     size:    20938752 sectors
     mode:    read/write

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   - hosts: all
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
            - sdb
           fs_type: xfs
           fs_label: label-name
           mount_point: /mnt/data
           encryption: true
           encryption_password: your-password
     roles:
      - rhel-system-roles.storage

   playbook.yml ファイルに、encryption_key、encryption_cipher、encryption_key_size、および encryption_luks バージョンなどの他の暗号化パラメーターを追加することもできます。

2. オプション:Playbook の構文を確認します。

   # ansible-playbook --syntax-check playbook.yml

3. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

検証

1. 暗号化ステータスを表示します。

   # cryptsetup status sdb
   
   /dev/mapper/sdb is active and is in use.
   type: LUKS2
   cipher: aes-xts-plain64
   keysize: 512 bits
   key location: keyring
   device: /dev/sdb
   [...]

2. 作成された LUKS 暗号化ボリュームを確認します。

   # cryptsetup luksDump /dev/sdb
   
   Version:       	2
   Epoch:         	6
   Metadata area: 	16384 [bytes]
   Keyslots area: 	33521664 [bytes]
   UUID:          	a4c6be82-7347-4a91-a8ad-9479b72c9426
   Label:         	(no label)
   Subsystem:     	(no subsystem)
   Flags:       	allow-discards
   
   Data segments:
     0: crypt
   	offset: 33554432 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   	sector: 4096 [bytes]
   [...]

3. storage ロールがサポートする playbook.yml ファイル内の cryptsetup パラメーターを表示します。

   # cat ~/playbook.yml
   
       - hosts: all
         vars:
           storage_volumes:
             - name: foo
               type: disk
               disks:
                - nvme0n1
               fs_type: xfs
               fs_label: label-name
               mount_point: /mnt/data
               encryption: true
               #encryption_password: passwdpasswd
               encryption_key: /home/passwd_key
               encryption_cipher: aes-xts-plain64
               encryption_key_size: 512
               encryption_luks_version: luks2
   
         roles:
          - rhel-system-roles.storage

手順

1. 暗号化されたボリュームを持つシステムに Clevis とそのピンをインストールするには、次のコマンドを実行します。

   # dnf install clevis

2. データを複号するには、clevis decrypt コマンドを実行して、JWE (JSON Web Encryption) 形式で暗号文を指定します。以下に例を示します。

   $ clevis decrypt < secret.jwe

手順

1. tang パッケージとその依存関係をインストールするには、root で以下のコマンドを実行します。

   # dnf install tang

2. 7500/tcp などの不要なポートを選択し、tangd サービスがそのポートにバインドできるようにします。

   # semanage port -a -t tangd_port_t -p tcp 7500

   ポートは 1 つのサービスのみで一度に使用できるため、すでに使用しているポートを使用しようとすると、ValueError:Port already defined エラーが発生します。

3. ファイアウォールのポートを開きます。

   # firewall-cmd --add-port=7500/tcp
   # firewall-cmd --runtime-to-permanent

4. tangd サービスを有効にします。

   # systemctl enable tangd.socket

5. オーバーライドファイルを作成します。

   # systemctl edit tangd.socket

6. 以下のエディター画面で、/etc/systemd/system/tangd.socket.d/ ディレクトリーにある空の override.conf ファイルを開き、次の行を追加して、Tang サーバーのデフォルトのポートを、80 から、以前取得した番号に変更します。

   [Socket]
   ListenStream=
   ListenStream=7500

   ファイルを保存して、エディターを終了します。

7. 変更した設定を再読み込みします。

   # systemctl daemon-reload

8. 設定が機能していることを確認します。

   # systemctl show tangd.socket -p Listen
   Listen=[::]:7500 (Stream)

9. tangd サービスを開始します。

   # systemctl restart tangd.socket

   tangd が、systemd のソケットアクティベーションメカニズムを使用しているため、最初に接続するとすぐにサーバーが起動します。最初の起動時に、一組の暗号鍵が自動的に生成されます。鍵の手動生成などの暗号化操作を実行するには、jose ユーティリティーを使用します。

手順

1. /var/db/tang 鍵データベースディレクトリーのすべての鍵の名前の前に . を指定して、アドバタイズメントに対して非表示にします。以下の例のファイル名は、Tang サーバーの鍵データベースディレクトリーにある一意のファイル名とは異なります。

   # cd /var/db/tang
   # ls -l
   -rw-r--r--. 1 root root 349 Feb  7 14:55 UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
   -rw-r--r--. 1 root root 354 Feb  7 14:55 y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
   # mv UV6dqXSwe1bRKG3KbJmdiR020hY.jwk .UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
   # mv y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk .y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk

2. 名前が変更され、Tang サーバーのアドバタイズに対してすべての鍵が非表示になっていることを確認します。

   # ls -l
   total 0

3. Tang サーバーの /var/db/tang で /usr/libexec/tangd-keygen コマンドを使用して新しい鍵を生成します。

   # /usr/libexec/tangd-keygen /var/db/tang
   # ls /var/db/tang
   3ZWS6-cDrCG61UPJS2BMmPU4I54.jwk zyLuX6hijUy_PSeUEFDi7hi38.jwk

4. Tang サーバーが、以下のように新規キーペアから署名キーを公開していることを確認します。

   # tang-show-keys 7500
   3ZWS6-cDrCG61UPJS2BMmPU4I54

5. NBDE クライアントで clevis luks report コマンドを使用して、Tang サーバーでアドバタイズされた鍵が同じままかどうかを確認します。clevis luks list コマンドを使用すると、関連するバインディングのあるスロットを特定できます。以下に例を示します。

   # clevis luks list -d /dev/sda2
   1: tang '{"url":"http://tang.srv"}'
   # clevis luks report -d /dev/sda2 -s 1
   ...
   Report detected that some keys were rotated.
   Do you want to regenerate luks metadata with "clevis luks regen -d /dev/sda2 -s 1"? [ynYN]

6. 新しい鍵の LUKS メタデータを再生成するには、直前のコマンドプロンプトで y を押すか、clevis luks regen コマンドを使用します。

   # clevis luks regen -d /dev/sda2 -s 1

7. すべての古いクライアントが新しい鍵を使用することを確認したら、Tang サーバーから古い鍵を削除できます。次に例を示します。

   # cd /var/db/tang
   # rm .*.jwk

手順

1. Web ブラウザーに以下のアドレスを入力して、RHEL Web コンソールを開きます。

   https://localhost:9090

   リモートシステムに接続する際に、localhost の部分をリモートサーバーのホスト名または IP アドレスに置き換えます。

2. 認証情報を指定して、ストレージ をクリックします。> をクリックして、Tang サーバーを使用してロックを解除する暗号化されたデバイスの詳細を展開し、Encryption をクリックします。

3. Keys セクションの + をクリックして Tang キーを追加します。

   

4. Tang サーバーのアドレスと、LUKS で暗号化したデバイスのロックを解除するパスワードを指定します。Add をクリックして確定します。

   

   以下のダイアログウインドウは、鍵ハッシュが一致することを確認するコマンドを提供します。

5. Tang サーバーのターミナルで、tang-show-keys コマンドを使用して、比較のためにキーハッシュを表示します。この例では、Tang サーバーはポート 7500 で実行されています。

   # tang-show-keys 7500
   fM-EwYeiTxS66X3s1UAywsGKGnxnpll8ig0KOQmr9CM

6. Web コンソールと前述のコマンドの出力のキーハッシュが同じ場合は、Trust key をクリックします。

   

7. 初期ブートシステムでディスクバインディングを処理できるようにするには、左側のナビゲーションバーの下部にある Terminal をクリックし、次のコマンドを入力します。

   # dnf install clevis-dracut
   # grubby --update-kernel=ALL --args="rd.neednet=1"
   # dracut -fv --regenerate-all

検証

1. 新規に追加された Tang キーが Keyserver タイプの Keys セクションに一覧表示されていることを確認します。

   

2. バインディングが初期ブートで使用できることを確認します。次に例を示します。

   # lsinitrd | grep clevis
   clevis
   clevis-pin-sss
   clevis-pin-tang
   clevis-pin-tpm2
   -rwxr-xr-x   1 root     root         1600 Feb 11 16:30 usr/bin/clevis
   -rwxr-xr-x   1 root     root         1654 Feb 11 16:30 usr/bin/clevis-decrypt
   ...
   -rwxr-xr-x   2 root     root           45 Feb 11 16:30 usr/lib/dracut/hooks/initqueue/settled/60-clevis-hook.sh
   -rwxr-xr-x   1 root     root         2257 Feb 11 16:30 usr/libexec/clevis-luks-askpass

手順

1. LUKS で暗号化した既存のボリュームを自動的にアンロックするには、サブパッケージの clevis-luks をインストールします。

   # dnf install clevis-luks

2. PBD 用 LUKS 暗号化ボリュームを特定します。次の例では、ブロックデバイスは /dev/sda2 と呼ばれています。

   # lsblk
   NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
   sda                                             8:0    0    12G  0 disk
   ├─sda1                                          8:1    0     1G  0 part  /boot
   └─sda2                                          8:2    0    11G  0 part
     └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
       ├─rhel-root                               253:0    0   9.8G  0 lvm   /
       └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]

3. clevis luks bind コマンドを使用して、ボリュームを Tang サーバーにバインドします。

   # clevis luks bind -d /dev/sda2 tang '{"url":"http://tang.srv"}'
   The advertisement contains the following signing keys:
   
   _OsIk0T-E2l6qjfdDiwVmidoZjA
   
   Do you wish to trust these keys? [ynYN] y
   You are about to initialize a LUKS device for metadata storage.
   Attempting to initialize it may result in data loss if data was
   already written into the LUKS header gap in a different format.
   A backup is advised before initialization is performed.
   
   Do you wish to initialize /dev/sda2? [yn] y
   Enter existing LUKS password:

   このコマンドは、以下の 4 つの手順を実行します。

   1. LUKS マスター鍵と同じエントロピーを使用して、新しい鍵を作成します。
   2. Clevis で新しい鍵を暗号化します。
   3. LUKS2 ヘッダートークンに Clevis JWE オブジェクトを保存するか、デフォルト以外の LUKS1 ヘッダーが使用されている場合は LUKSMeta を使用します。
   4. LUKS を使用する新しい鍵を有効にします。
   注記

   バインド手順では、空き LUKS パスワードスロットが少なくとも 1 つあることが前提となっています。そのスロットの 1 つを clevis luks bind コマンドが使用します。

   ボリュームは、現在、既存のパスワードと Clevis ポリシーを使用してロックを解除できます。

4. システムの起動プロセスの初期段階でディスクバインディングを処理するようにするには、インストール済みのシステムで dracut ツールを使用します。

   # dnf install clevis-dracut

   RHEL 8 では、Clevis はホスト固有の設定オプションを指定せずに汎用 initrd (initial ramdisk) を生成し、カーネルコマンドラインに rd.neednet=1 などのパラメーターを自動的に追加しません。初期の起動時にネットワークを必要とする Tang ピンを使用する場合は、--hostonly-cmdline 引数を使用し、dracut が Tang バインディングを検出すると rd.neednet=1 を追加します。

   # dracut -fv --regenerate-all --hostonly-cmdline

   または、/etc/dracut.conf.d/ に .conf ファイルを作成し、以下のように hostonly_cmdline=yes オプションを追加します。

   # echo "hostonly_cmdline=yes" > /etc/dracut.conf.d/clevis.conf

   注記

   Clevis がインストールされているシステムで grubby ツールを使用して、システム起動時の早い段階で Tang ピンのネットワークを利用できるようにすることができます。

   # grubby --update-kernel=ALL --args="rd.neednet=1"

   次に、--hostonly-cmdline なしで dracut を使用できます。

   # dracut -fv --regenerate-all

検証

1. Clevis JWE オブジェクトが LUKS ヘッダーに適切に置かれていることを確認するには、clevis luks list コマンドを使用します。

   # clevis luks list -d /dev/sda2
   1: tang '{"url":"http://tang.srv:port"}'

手順

1. LUKS で暗号化した既存のボリュームを自動的にアンロックするには、サブパッケージの clevis-luks をインストールします。

   # dnf install clevis-luks

2. PBD 用 LUKS 暗号化ボリュームを特定します。次の例では、ブロックデバイスは /dev/sda2 と呼ばれています。

   # lsblk
   NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
   sda                                             8:0    0    12G  0 disk
   ├─sda1                                          8:1    0     1G  0 part  /boot
   └─sda2                                          8:2    0    11G  0 part
     └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
       ├─rhel-root                               253:0    0   9.8G  0 lvm   /
       └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]

3. clevis luks bind コマンドを使用して、ボリュームを TPM 2.0 デバイスにバインドします。以下に例を示します。

   # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa"}'
   ...
   Do you wish to initialize /dev/sda2? [yn] y
   Enter existing LUKS password:

   このコマンドは、以下の 4 つの手順を実行します。

   1. LUKS マスター鍵と同じエントロピーを使用して、新しい鍵を作成します。
   2. Clevis で新しい鍵を暗号化します。
   3. LUKS2 ヘッダートークンに Clevis JWE オブジェクトを保存するか、デフォルト以外の LUKS1 ヘッダーが使用されている場合は LUKSMeta を使用します。

   4. LUKS を使用する新しい鍵を有効にします。

      注記

      バインド手順では、空き LUKS パスワードスロットが少なくとも 1 つあることが前提となっています。そのスロットの 1 つを clevis luks bind コマンドが使用します。

      あるいは、特定の Platform Configuration Registers (PCR) の状態にデータをシールする場合は、clevis luks bind コマンドに pcr_bank と pcr_ids 値を追加します。以下に例を示します。

      # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa","pcr_bank":"sha256","pcr_ids":"0,1"}'

      警告

      PCR ハッシュ値がシール時に使用されるポリシーと一致し、ハッシュを書き換えることができる場合にのみ、データをアンシールできるため、PCR の値が変更された場合、暗号化されたボリュームのロックを手動で解除できる強力なパスフレーズを追加します。

      shim-x64 パッケージのアップグレード後にシステムが暗号化されたボリュームのロックを自動的に解除できない場合は、KCS の記事Clevis TPM2 no longer decrypts LUKS devices after a restartの手順に従ってください。

4. ボリュームは、現在、既存のパスワードと Clevis ポリシーを使用してロックを解除できます。

5. システムの起動プロセスの初期段階でディスクバインディングを処理するようにするには、インストール済みのシステムで dracut ツールを使用します。

   # dnf install clevis-dracut
   # dracut -fv --regenerate-all

検証

1. Clevis JWE オブジェクトが LUKS ヘッダーに適切に置かれていることを確認するには、clevis luks list コマンドを使用します。

   # clevis luks list -d /dev/sda2
   1: tpm2 '{"hash":"sha256","key":"rsa"}'

手順

1. /dev/sda2 などのボリュームがどの LUKS バージョンであるかを確認し、Clevis にバインドされているスロットおよびトークンを特定します。

   # cryptsetup luksDump /dev/sda2
   LUKS header information
   Version:        2
   ...
   Keyslots:
     0: luks2
   ...
   1: luks2
         Key:        512 bits
         Priority:   normal
         Cipher:     aes-xts-plain64
   ...
         Tokens:
           0: clevis
                 Keyslot:  1
   ...

   上記の例では、Clevis トークンは 0 で識別され、関連付けられた鍵スロットは 1 です。

2. LUKS2 暗号化の場合は、トークンを削除します。

   # cryptsetup token remove --token-id 0 /dev/sda2

3. デバイスが LUKS1 で暗号化されていて、Version:1 という文字列が cryptsetup luksDump コマンドの出力に含まれている場合は、luksmeta wipe コマンドでこの追加手順を実行します。

   # luksmeta wipe -d /dev/sda2 -s 1

4. Clevis パスフレーズを含む鍵スロットを削除します。

   # cryptsetup luksKillSlot /dev/sda2 1

手順

1. 一時パスワードを使用して、LUKS 暗号化が有効になっているディスクを、/boot 以外のすべてのマウントポイントで分割するように、キックスタートに指示します。パスワードは、登録プロセスの手順に使用するための一時的なものです。

   part /boot --fstype="xfs" --ondisk=vda --size=256
   part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass

   OSPP 準拠のシステムには、より複雑な設定が必要であることに注意してください。次に例を示します。

   part /boot --fstype="xfs" --ondisk=vda --size=256
   part / --fstype="xfs" --ondisk=vda --size=2048 --encrypted --passphrase=temppass
   part /var --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /tmp --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /home --fstype="xfs" --ondisk=vda --size=2048 --grow --encrypted --passphrase=temppass
   part /var/log --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /var/log/audit --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass

2. 関連する Clevis パッケージを %packages セクションに追加して、インストールします。

   %packages
   clevis-dracut
   clevis-luks
   clevis-systemd
   %end

3. オプションで、必要に応じて暗号化されたボリュームのロックを手動で解除できるようにするには、一時パスフレーズを削除する前に強力なパスフレーズを追加します。詳細については、How to add a passphrase, key, or keyfile to an existing LUKS device の記事を参照してください。

4. clevis luks bind を呼び出して、%post セクションのバインディングを実行します。その後、一時パスワードを削除します。

   %post
   clevis luks bind -y -k - -d /dev/vda2 \
   tang '{"url":"http://tang.srv"}' <<< "temppass"
   cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
   dracut -fv --regenerate-all
   %end

   設定が起動初期にネットワークを必要とする Tang ピンに依存している場合、または静的 IP 設定の NBDE クライアントを使用している場合は、Configuring manual enrollment of LUKS-encrypted volumesに従って dracut コマンドを変更する必要があります。

   clevis luks bind コマンドの -y オプションは、RHEL 8.3 から使用できることに注意してください。RHEL 8.2 以前では、 clevis luks bind コマンドで -y を -f に置き換え、Tang サーバーからアドバタイズメントをダウンロードします。

   %post
   curl -sfg http://tang.srv/adv -o adv.jws
   clevis luks bind -f -k - -d /dev/vda2 \
   tang '{"url":"http://tang.srv","adv":"adv.jws"}' <<< "temppass"
   cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
   dracut -fv --regenerate-all
   %end

   警告

   cryptsetup luksRemoveKey コマンドは、それを適用する LUKS2 デバイスがそれ以上に管理されるのを防ぎます。LUKS1 デバイスに対してのみ dmsetup コマンドを使用して、削除されたマスターキーを回復できます。

手順

1. USB ドライブなど、LUKS で暗号化したリムーバブルストレージデバイスを自動的にアンロックするには、clevis-udisks2 パッケージをインストールします。

   # dnf install clevis-udisks2

2. システムを再起動し、LUKS で暗号化したボリュームの手動登録の設定 に従って、clevis luks bind コマンドを使用したバインディング手順を実行します。以下に例を示します。

   # clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'

3. LUKS で暗号化したリムーバブルデバイスは、GNOME デスクトップセッションで自動的にアンロックできるようになりました。Clevis ポリシーにバインドするデバイスは、clevis luks unlock コマンドでアンロックできます。

   # clevis luks unlock -d /dev/sdb1

手順

1. registry.redhat.io レジストリーから tang コンテナーイメージをプルします。

   # podman pull registry.redhat.io/rhel9/tang

2. コンテナーを実行し、そのポートを指定して Tang 鍵へのパスを指定します。上記の例では、tang コンテナーを実行し、ポート 7500 を指定し、/var/db/tang ディレクトリーの Tang 鍵へのパスを示します。

   # podman run -d -p 7500:7500 -v tang-keys:/var/db/tang --name tang registry.redhat.io/rhel9/tang

   Tang はデフォルトでポート 80 を使用しますが、Apache HTTP サーバーなどの他のサービスと共存する可能性があることに注意してください。

3. (必要に応じて) セキュリティーを強化する場合は、Tang 鍵を定期的にローテーションします。tangd-rotate-keys スクリプトを使用できます。以下に例を示します。

   # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/rhel9/tang tangd-rotate-keys -v -d /var/db/tang
   Rotated key 'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk' -> .'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk'
   Rotated key 'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk' -> .'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk'
   Created new key GrMMX_WfdqomIU_4RyjpcdlXb0E.jwk
   Created new key _dTTfn17sZZqVAp80u3ygFDHtjk.jwk
   Keys rotated successfully.

手順

1. Tang サーバーの設定が含まれる Playbook を準備します。ゼロから開始するか、または /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ ディレクトリーにある Playbook のいずれかのサンプルを使用することができます。

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml

2. 選択したテキストエディターで Playbook を編集します。以下に例を示します。

   # vi my-tang-playbook.yml

3. 必要なパラメーターを追加します。以下の Playbook の例では、Tang サーバーのデプロイと鍵のローテーションを確実に実行します。

   ---
   - hosts: all
   
     vars:
       nbde_server_rotate_keys: yes
       nbde_server_manage_firewall: true
       nbde_server_manage_selinux: true
   
     roles:
       - rhel-system-roles.nbde_server

   注記

   nbde_server_manage_firewall と nbde_server_manage_selinux は両方とも true に設定されているため、nbde_server ロールは firewall と selinux ロールを使用して、nbde_server ロールが使用するポートを管理します。

4. 終了した Playbook を適用します。

   # ansible-playbook -i inventory-file my-tang-playbook.yml

   ここで * inventory-file はインベントリーファイル、* logging-playbook.yml は Playbook も置き換えます。

手順

1. Clevis クライアントの設定が含まれる Playbook を準備します。ゼロから開始するか、または /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/ ディレクトリーにある Playbook のいずれかのサンプルを使用することができます。

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml

2. 選択したテキストエディターで Playbook を編集します。以下に例を示します。

   # vi my-clevis-playbook.yml

3. 必要なパラメーターを追加します。以下の Playbook の例では、2 つの Tang サーバーのうち少なくとも 1 台が利用可能な場合に、LUKS で暗号化した 2 つのボリュームを自動的にアンロックするように Clevis クライアントを設定します。

   ---
   - hosts: all
   
     vars:
       nbde_client_bindings:
         - device: /dev/rhel/root
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
         - device: /dev/rhel/swap
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
   
     roles:
       - rhel-system-roles.nbde_client

4. 終了した Playbook を適用します。

   # ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml

ファイルシステムのルールの例

1. すべての書き込みアクセスと /etc/passwd ファイルのすべての属性変更をログに記録するルールを定義するには、次のコマンドを実行します。

   # auditctl -w /etc/passwd -p wa -k passwd_changes

2. すべての書き込みアクセスと、/etc/selinux/ ディレクトリー内の全ファイルへのアクセスと、その属性変更をすべてログに記録するルールを定義するには、次のコマンドを実行します。

   # auditctl -w /etc/selinux/ -p wa -k selinux_changes

システムロールのルールの例

1. システムで 64 ビットアーキテクチャーが使用され、システムコールの adjtimex または settimeofday がプログラムにより使用されるたびにログエントリーを作成するルールを定義するには、次のコマンドを実行します。

   # auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change

2. ユーザー ID が 1000 以上のシステムユーザーがファイルを削除したりファイル名を変更するたびに、ログエントリーを作成するルールを定義するには、次のコマンドを実行します。

   # auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

   -F auid!=4294967295 オプションが、ログイン UID が設定されていないユーザーを除外するために使用されています。

手順

1. /usr/lib/systemd/system/auditd.service ファイルを /etc/systemd/system/ ディレクトリーにコピーします。

   # cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/

2. 任意のテキストエディターで /etc/systemd/system/auditd.service ファイルを編集します。以下に例を示します。

   # vi /etc/systemd/system/auditd.service

3. augenrules を含む行をコメントアウトし、auditctl -R コマンドを含む行のコメント設定を解除します。

   #ExecStartPost=-/sbin/augenrules --load
   ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules

4. systemd デーモンを再読み込みして、auditd.service ファイルの変更を取得します。

   # systemctl daemon-reload

5. auditd サービスを再起動します。

   # service auditd restart

手順

1. 事前設定されたルールファイル 44-installers.rules を /usr/share/audit/sample-rules/ ディレクトリーから /etc/audit/rules.d/ ディレクトリーにコピーします。

   # cp /usr/share/audit/sample-rules/44-installers.rules /etc/audit/rules.d/

2. 監査ルールを読み込みます。

   # augenrules --load

検証

1. 読み込まれたルールを一覧表示します。

   # auditctl -l
   -p x-w /usr/bin/dnf-3 -k software-installer
   -p x-w /usr/bin/yum -k software-installer
   -p x-w /usr/bin/pip -k software-installer
   -p x-w /usr/bin/npm -k software-installer
   -p x-w /usr/bin/cpan -k software-installer
   -p x-w /usr/bin/gem -k software-installer
   -p x-w /usr/bin/luarocks -k software-installer

2. インストールを実行します。以下に例を示します

   # dnf reinstall -y vim-enhanced

3. Audit ログで最近のインストールイベントを検索します。次に例を示します。

   # ausearch -ts recent -k software-installer
   ––––
   time->Thu Dec 16 10:33:46 2021
   type=PROCTITLE msg=audit(1639668826.074:298): proctitle=2F7573722F6C6962657865632F706C6174666F726D2D707974686F6E002F7573722F62696E2F646E66007265696E7374616C6C002D790076696D2D656E68616E636564
   type=PATH msg=audit(1639668826.074:298): item=2 name="/lib64/ld-linux-x86-64.so.2" inode=10092 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=PATH msg=audit(1639668826.074:298): item=1 name="/usr/libexec/platform-python" inode=4618433 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=PATH msg=audit(1639668826.074:298): item=0 name="/usr/bin/dnf" inode=6886099 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpm_exec_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=CWD msg=audit(1639668826.074:298): cwd="/root"
   type=EXECVE msg=audit(1639668826.074:298): argc=5 a0="/usr/libexec/platform-python" a1="/usr/bin/dnf" a2="reinstall" a3="-y" a4="vim-enhanced"
   type=SYSCALL msg=audit(1639668826.074:298): arch=c000003e syscall=59 success=yes exit=0 a0=55c437f22b20 a1=55c437f2c9d0 a2=55c437f2aeb0 a3=8 items=3 ppid=5256 pid=5375 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="dnf" exe="/usr/libexec/platform-python3.6" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="software-installer"

手順

1. fapolicyd パッケージをインストールします。

   # dnf install fapolicyd

2. fapolicyd サービスを有効にして開始します。

   # systemctl enable --now fapolicyd

検証

1. fapolicyd サービスが正しく実行されていることを確認します。

   # systemctl status fapolicyd
   ● fapolicyd.service - File Access Policy Daemon
      Loaded: loaded (/usr/lib/systemd/system/fapolicyd.service; enabled; vendor p>
      Active: active (running) since Tue 2019-10-15 18:02:35 CEST; 55s ago
     Process: 8818 ExecStart=/usr/sbin/fapolicyd (code=exited, status=0/SUCCESS)
    Main PID: 8819 (fapolicyd)
       Tasks: 4 (limit: 11500)
      Memory: 78.2M
      CGroup: /system.slice/fapolicyd.service
              └─8819 /usr/sbin/fapolicyd
   
   Oct 15 18:02:35 localhost.localdomain systemd[1]: Starting File Access Policy D>
   Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Initialization of the da>
   Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Reading RPMDB into memory
   Oct 15 18:02:35 localhost.localdomain systemd[1]: Started File Access Policy Da>
   Oct 15 18:02:36 localhost.localdomain fapolicyd[8819]: Creating database

2. root 権限のないユーザーとしてログインし、以下のように fapolicyd が機能していることを確認します。

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

手順

1. カスタムバイナリーを必要なディレクトリーにコピーします。以下に例を示します。

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

2. カスタムバイナリーを信頼済みとしてマークし、対応するエントリーを /etc/fapolicyd/trust.d/ の myapp ファイルに保存します。

   # fapolicyd-cli --file add /tmp/ls --trust-file myapp

   • --trust-file オプションをスキップすると、前のコマンドは対応する行を /etc/fapolicyd/fapolicyd.trust に追加します。
   • ディレクトリー内のすべての既存ファイルを信頼済みとしてマークするには、--file オプションの引数としてディレクトリーパスを指定します。たとえば、fapolicyd-cli --file add/tmp/my_bin_dir/--trust-file myapp です。

3. fapolicyd データベースを更新します。

   # fapolicyd-cli --update

検証

1. たとえば、カスタムバイナリーが実行できることを確認します。

   $ /tmp/ls
   ls

手順

1. カスタムバイナリーを必要なディレクトリーにコピーします。以下に例を示します。

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

2. fapolicyd サービスを停止します。

   # systemctl stop fapolicyd

3. デバッグモードを使用して、対応するルールを識別します。fapolicyd --debug コマンドの出力は冗長で、Ctrl+C を押すか、対応するプロセスを強制終了するだけで停止できるため、エラー出力をファイルにリダイレクトします。この場合、--debug の代わりに --debug-deny オプションを使用して、アクセス拒否のみに出力を制限できます。

   # fapolicyd --debug-deny 2> fapolicy.output &
   [1] 51341

   または、別の端末で fapolicyd デバッグモードを実行できます。

4. fapolicyd が拒否したコマンドを繰り返します。

   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

5. デバッグモードをフォアグラウンドで再開し、Ctrl+C を押して停止します。

   # fg
   fapolicyd --debug 2> fapolicy.output
   ^C
   ...

   または、fapolicyd デバッグモードのプロセスを強制終了します。

   # kill 51341

6. アプリケーションの実行を拒否するルールを見つけます。

   # cat fapolicy.output | grep 'deny_audit'
   ...
   rule=13 dec=deny_audit perm=execute auid=0 pid=6855 exe=/usr/bin/bash : path=/tmp/ls ftype=application/x-executable trust=0

7. カスタムバイナリーの実行を妨げたルールを含むファイルを見つけます。この場合、deny_audit perm=execute ルールは 90-deny-execute.rules ファイルに属します。

   # ls /etc/fapolicyd/rules.d/
   10-languages.rules  40-bad-elf.rules	   72-shell.rules
   20-dracut.rules     41-shared-obj.rules    90-deny-execute.rules
   21-updaters.rules   42-trusted-elf.rules   95-allow-open.rules
   30-patterns.rules   70-trusted-lang.rules
   
   
   # cat /etc/fapolicyd/rules.d/90-deny-execute.rules
   # Deny execution for anything untrusted
   
   deny_audit perm=execute all : all

8. /etc/fapolicyd/rules.d/ ディレクトリー内のカスタムバイナリーの実行を拒否するルールを含むルールファイルの前にあるファイルに、新しい allow ルールを追加します。

   # touch /etc/fapolicyd/rules.d/80-myapps.rules
   # vi /etc/fapolicyd/rules.d/80-myapps.rules

   以下のルールを 80-myapps.rules ファイルに挿入します。

   allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0

   または、/etc/fapolicyd/rules.d/ のルールファイルに次のルールを追加して、/tmp ディレクトリー内のすべてのバイナリーの実行を許可することもできます。

   allow perm=execute exe=/usr/bin/bash trust=1 : dir=/tmp/ trust=0

9. カスタムバイナリーのコンテンツの変更を防ぐには、SHA-256 チェックサムを使用して必要なルールを定義します。

   $ sha256sum /tmp/ls
   780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836  ls

   ルールを以下の定義に変更します。

   allow perm=execute exe=/usr/bin/bash trust=1 : sha256hash=780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836

10. コンパイル済みのリストが /etc/fapolicyd/rules.d/ に設定されているルールと異なることを確認し、/etc/fapolicyd/compiled.rules ファイルに保存されているリストを更新します。

    # fagenrules --check
    /usr/sbin/fagenrules: Rules have changed and should be updated
    # fagenrules --load

11. カスタムルールが、実行を妨げたルールの前に fapolicyd ルールのリストにあることを確認します。

    # fapolicyd-cli --list
    ...
    13. allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0
    14. deny_audit perm=execute all : all
    ...

12. fapolicyd サービスを開始します。

    # systemctl start fapolicyd

検証

1. たとえば、カスタムバイナリーが実行できることを確認します。

   $ /tmp/ls
   ls

手順

1. 任意のテキストエディターで /etc/fapolicyd/fapolicyd.conf ファイルを開きます。以下に例を示します。

   # vi /etc/fapolicyd/fapolicyd.conf

2. 整合性 オプションの値を none から sha256 に変更し、ファイルを保存してエディターを終了します。

   integrity = sha256

3. fapolicyd サービスを再起動します。

   # systemctl restart fapolicyd

検証

1. 検証に使用するファイルのバックアップを作成します。

   # cp /bin/more /bin/more.bak

2. /bin/more バイナリーの内容を変更します。

   # cat /bin/less > /bin/more

3. 変更したバイナリーを一般ユーザーとして使用します。

   # su example.user
   $ /bin/more /etc/redhat-release
   bash: /bin/more: Operation not permitted

4. 変更を元に戻します。

   # mv -f /bin/more.bak /bin/more