SELinux の使用

手順

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

   # vi /etc/selinux/config

2. SELINUX=permissive オプションを設定します。

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=permissive
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

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

   # reboot

検証

1. システムの再起動後に、getenforce コマンドが Permissive を返すことを確認します。

   $ getenforce
   Permissive

手順

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

   # vi /etc/selinux/config

2. SELINUX=enforcing オプションを設定します。

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=enforcing
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

3. 変更を保存して、システムを再起動します。

   # reboot

   次にシステムを起動する際に、SELinux はシステム内のファイルおよびディレクトリーのラベルを再設定し、SELinux が無効になっている間に作成したファイルおよびディレクトリーに SELinux コンテキストを追加します。

検証

1. システムの再起動後に、getenforce コマンドが Enforcing を返すことを確認します。

   $ getenforce
   Enforcing

手順

1. SELinux を Permissive モードで有効にします。詳細は Permissive モードへの変更 を参照してください。

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

   # reboot

3. SELinux 拒否メッセージを確認します。詳細は、SELinux 拒否の特定 を参照してください。

4. 次の再起動時に、ファイルが再ラベル付けされていることを確認します。

   # fixfiles -F onboot

   これにより、-F オプションを含む /.autorelabel ファイルが作成されます。

   警告

   fixfiles -F onboot コマンドを入力する前に、必ず Permissive モードに切り替えてください。

   デフォルトでは、autorelabel はシステムで使用可能な CPU コアと同じ数のスレッドを並列に使用します。ラベルの自動再設定中に単一のスレッドのみを使用するには、fixfiles -T 1 onboot コマンドを使用します。

5. 拒否がない場合は、Enforcing モードに切り替えます。詳細は システムの起動時に SELinux モードの変更 を参照してください。

検証

1. システムの再起動後に、getenforce コマンドが Enforcing を返すことを確認します。

   $ getenforce
   Enforcing

手順

1. ブートローダーを設定して、カーネルコマンドラインに selinux=0 を追加します。

   $ sudo grubby --update-kernel ALL --args selinux=0

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

   $ reboot

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

   # vi /etc/selinux/config

2. SELINUX=disabled オプションを設定します。

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=disabled
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

3. 変更を保存して、システムを再起動します。

   # reboot

手順

1. 次のコマンドを入力して、<example_user> という名前の新しい Linux ユーザーを作成します。

   # useradd <example_user>

2. Linux の <example_user> ユーザーにパスワードを割り当てるには、次のコマンドを実行します。

   # passwd <example_user>
   Changing password for user <example_user>.
   New password:
   Retype new password:
   passwd: all authentication tokens updated successfully.

3. 現在のセッションからログアウトします。
4. Linux の <example_user> ユーザーとしてログインします。ログインすると、PAM モジュール pam_selinux は Linux ユーザーを SELinux ユーザー (この場合は unconfined_u) に自動的にマッピングし、作成された SELinux コンテキストを設定します。Linux ユーザーのシェルはこのコンテキストで起動します。

検証

1. <example_user> ユーザーとしてログインしたら、Linux ユーザーのコンテキストを確認します。

   $ id -Z
   unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

手順

1. 次のコマンドを入力して、<example_user> という名前の新しい Linux ユーザーを作成し、それを SELinux Staff_u ユーザーにマッピングします。

   # useradd -Z staff_u <example_user>

2. Linux の <example_user> ユーザーにパスワードを割り当てるには、次のコマンドを実行します。

   # passwd <example_user>
   Changing password for user <example_user>.
   New password:
   Retype new password:
   passwd: all authentication tokens updated successfully.

3. 現在のセッションからログアウトします。
4. Linux の <example_user> ユーザーとしてログインします。ユーザーのシェルは staff_u コンテキストで起動します。

検証

1. <example_user> ユーザーとしてログインしたら、Linux ユーザーのコンテキストを確認します。

   $ id -Z
   uid=1000(<example_user>) gid=1000(<example_user>) groups=1000(<example_user>) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023

手順

1. SELinux ログインレコードのリストを表示します。このリストには、SELinux ユーザーへの Linux ユーザーのマッピングが表示されます。

   # semanage login -l
   
   Login Name    SELinux User  MLS/MCS Range   Service
   
   __default__   unconfined_u  s0-s0:c0.c1023       *
   root          unconfined_u  s0-s0:c0.c1023       *

2. 明示的なマッピングのないすべてのユーザーを表す __default__ ユーザーを、SELinux ユーザー user_u にマッピングします。

   # semanage login -m -s user_u -r s0 __default__

検証

1. __default__ ユーザーが SELinux ユーザー user_uにマッピングされていることを確認します。

   # semanage login -l
   
   Login Name    SELinux User   MLS/MCS Range    Service
   
   __default__   user_u         s0               *
   root          unconfined_u   s0-s0:c0.c1023   *

2. 新規ユーザーのプロセスが SELinux コンテキスト user_u:user_r:user_t:s0 で実行されることを確認します。

   1. 新しいユーザーを作成します。

      # adduser <example_user>

   2. <example_user> のパスワードを定義します。

      # passwd <example_user>

   3. root としてログアウトし、新規ユーザーとしてログインします。

   4. ユーザーの ID のセキュリティーコンテキストを表示します。

      [<example_user>@localhost ~]$ id -Z
      user_u:user_r:user_t:s0

   5. ユーザーの現在のプロセスのセキュリティーコンテキストを表示します。

      [<example_user>@localhost ~]$ ps axZ
      LABEL                           PID TTY      STAT   TIME COMMAND
      -                                 1 ?        Ss     0:05 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
      -                              3729 ?        S      0:00 (sd-pam)
      user_u:user_r:user_t:s0        3907 ?        Ss     0:00 /usr/lib/systemd/systemd --user
      -                              3911 ?        S      0:00 (sd-pam)
      user_u:user_r:user_t:s0        3918 ?        S      0:00 sshd: <example_user>@pts/0
      user_u:user_r:user_t:s0        3922 pts/0    Ss     0:00 -bash
      user_u:user_r:user_dbusd_t:s0  3969 ?        Ssl    0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
      user_u:user_r:user_t:s0        3971 pts/0    R+     0:00 ps axZ

手順

1. 必要に応じて、sysadm_u ユーザーが SSH を使用してシステムに接続できるようにするには、次のコマンドを実行します。

   # setsebool -P ssh_sysadm_login on

2. 新しいユーザーまたは既存のユーザーを sysadm_u SELinux ユーザーにマッピングします。

   • 新規ユーザーをマッピングするには、新規ユーザーを wheel ユーザーグループに追加し、そのユーザーを SELinux ユーザー sysadm_u にマッピングします。

     # adduser -G wheel -Z sysadm_u <example_user>

   • 既存のユーザーをマッピングするには、ユーザーを wheel ユーザーグループに追加し、そのユーザーを SELinux ユーザー sysadm_u にマッピングします。

     # usermod -G wheel -Z sysadm_u <example_user>

3. ユーザーのホームディレクトリーのコンテキストを復元します。

   # restorecon -R -F -v /home/<example_user>

検証

1. <example_user> が、SELinux ユーザー sysadm_u にマッピングされていることを確認します。

   # semanage login -l | grep <example_user>
   <example_user>     sysadm_u    s0-s0:c0.c1023   *

2. SSH などを使用して <example_user> としてログインし、ユーザーのセキュリティーコンテキストを表示します。

   [<example_user>@localhost ~]$ id -Z
   sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

3. root ユーザーに切り替えます。

   $ sudo -i
   [sudo] password for <example_user>:

4. セキュリティーコンテキストが変更されていないことを確認します。

   # id -Z
   sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

5. sshd サービスを再起動するなど、管理タスクを実行します。

   # systemctl restart sshd

   出力がない場合は、コマンドが正常に完了します。

   コマンドが正常に完了しない場合は、以下のメッセージが表示されます。

   Failed to restart sshd.service: Access denied
   See system logs and 'systemctl status sshd.service' for details.

手順

1. 新規または既存のユーザーを staff_u SELinux ユーザーにマッピングします。

   1. 新規ユーザーをマッピングするには、新規ユーザーを wheel ユーザーグループに追加し、そのユーザーを SELinux ユーザー staff_u にマッピングします。

      # adduser -G wheel -Z staff_u <example_user>

   2. 既存のユーザーをマッピングするには、ユーザーを Wheel ユーザーグループに追加し、そのユーザーを SELinux ユーザー staff_u にマッピングします。

      # usermod -G wheel -Z staff_u <example_user>

2. ユーザーのホームディレクトリーのコンテキストを復元します。

   # restorecon -R -F -v /home/<example_user>

3. <example_user> が SELinux 管理者ロールを取得できるようにするには、/etc/sudoers.d/ ディレクトリーに新規ファイルを作成します。以下に例を示します。

   # visudo -f /etc/sudoers.d/<example_user>

4. 以下の行を新規ファイルに追加します。

   <example_user> ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL

検証

1. <example_user> が SELinux ユーザー staff_u にマッピングされていることを確認します。

   # semanage login -l | grep <example_user>
   <example_user>     staff_u    s0-s0:c0.c1023   *

2. SSH などを使用して <example_user> としてログインし、root ユーザーに切り替えます。

   [<example_user>@localhost ~]$ sudo -i
   [sudo] password for <example_user>:

3. root セキュリティーコンテキストを表示します。

   # id -Z
   staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

4. sshd サービスを再起動するなど、管理タスクを実行します。

   # systemctl restart sshd

   出力がない場合は、コマンドが正常に完了します。

   コマンドが正常に完了しない場合は、以下のメッセージが表示されます。

   Failed to restart sshd.service: Access denied
   See system logs and 'systemctl status sshd.service' for details.

手順

1. httpd サービスを起動して、ステータスを確認します。

   # systemctl start httpd
   # systemctl status httpd
   ...
   httpd[14523]: (13)Permission denied: AH00072: make_sock: could not bind to address [::]:3131
   ...
   systemd[1]: Failed to start The Apache HTTP Server.
   ...

2. SELinux ポリシーは、httpd がポート 80 で実行していることを前提としています。

   # semanage port -l | grep http
   http_cache_port_t              tcp      8080, 8118, 8123, 10001-10010
   http_cache_port_t              udp      3130
   http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
   pegasus_http_port_t            tcp      5988
   pegasus_https_port_t           tcp      5989

3. ポート 3131 の SELinux タイプを、ポート 80 に一致させるように変更します。

   # semanage port -a -t http_port_t -p tcp 3131

4. httpd を再開します。

   # systemctl start httpd

5. ただし、コンテンツにはアクセスできません。

   # wget localhost:3131/index.html
   ...
   HTTP request sent, awaiting response... 403 Forbidden
   ...

   sealert ツールの理由を確認します。

   # sealert -l "*"
   ...
   SELinux is preventing httpd from getattr access on the file /var/test_www/html/index.html.
   ...

6. matchpathcon ツールを使用して、標準パスと新規パスの SELinux タイプを比較します。

   # matchpathcon /var/www/html /var/test_www/html
   /var/www/html       system_u:object_r:httpd_sys_content_t:s0
   /var/test_www/html  system_u:object_r:var_t:s0

7. 新しい /var/test_www/html/ コンテンツディレクトリーの SELinux タイプを、デフォルトの /var/ ディレクトリーのタイプに変更します。

   # semanage fcontext -a -e /var/www /var/test_www

8. 再帰的に、/var ディレクトリーのラベルを再設定します。

   # restorecon -Rv /var/
   ...
   Relabeled /var/test_www/html from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0
   Relabeled /var/test_www/html/index.html from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0

検証

1. httpd サービスが実行していることを確認します。

   # systemctl status httpd
   ...
   Active: active (running)
   ...
   systemd[1]: Started The Apache HTTP Server.
   httpd[14888]: Server configured, listening on: port 3131
   ...

2. Apache HTTP サーバーが提供するコンテンツがアクセスできることを確認します。

   # wget localhost:3131/index.html
   ...
   HTTP request sent, awaiting response... 200 OK
   Length: 0 [text/html]
   Saving to: ‘index.html’
   ...

手順

1. NFS、CIFS、および Apache に関する SELinux ブール値を特定します。

   # semanage boolean -l | grep 'nfs\|cifs' | grep httpd
   httpd_use_cifs                 (off  ,  off)  Allow httpd to access cifs file systems
   httpd_use_nfs                  (off  ,  off)  Allow httpd to access nfs file systems

2. ブール値の現在の状態をリスト表示します。

   $ getsebool -a | grep 'nfs\|cifs' | grep httpd
   httpd_use_cifs --> off
   httpd_use_nfs --> off

3. 指定されたブール値を有効にします。

   # setsebool httpd_use_nfs on
   # setsebool httpd_use_cifs on

   注記

   setsebool で -P オプションを使用使用すると、システムを再起動しても変更が持続します。setsebool -P コマンドは、ポリシー全体を再構築する必要がありますが、設定によっては少し時間がかかる場合があります。

検証

1. ブール値が on になっていることを確認します。

   $ getsebool -a | grep 'nfs\|cifs' | grep httpd
   httpd_use_cifs --> on
   httpd_use_nfs --> on

手順

1. SELinux 関連のすべてのトピックをリスト表示し、設定するコンポーネントに結果を絞り込みます。以下に例を示します。

   # man -k selinux | grep samba
   samba_net_selinux (8) - Security Enhanced Linux Policy for the samba_net processes
   samba_selinux (8)    - Security Enhanced Linux Policy for the smbd processes
   …

   お客様の状況に関連する man ページで、関連する SELinux ブール値、ポートタイプ、およびファイルタイプを見つけます。

   man -k selinux または apropos selinux コマンドを使用するには、先に selinux-policy-doc パッケージをインストールする必要があることに注意してください。

2. semanage fcontext -l コマンドを使用すると、デフォルトの場所にあるプロセスのデフォルトのマッピングを表示できます。次に例を示します。

   # semanage fcontext -l | grep samba
   …
   /var/cache/samba(/.*)?                             all files          system_u:object_r:samba_var_t:s0
   …
   /var/spool/samba(/.*)?                             all files          system_u:object_r:samba_spool_t:s0
   …

3. sesearch コマンドを使用して、デフォルトの SELinux ポリシーのルールを表示します。対応するルールをリスト表示することで、使用するタイプとブール値を見つけることができます。次に例を示します。

   $ sesearch -A | grep samba | grep httpd
   …
   allow httpd_t cifs_t:dir { getattr open search }; [ use_samba_home_dirs && httpd_enable_homedirs ]:True
   …

4. 場合によっては、SELinux ブール値が、設定の問題に対する最も簡単な解決策であることがあります。getsebool -a コマンドを使用すると、使用可能なすべてのブール値とその値を表示できます。次に例を示します。

   $ getsebool -a | grep homedirs
   git_cgi_enable_homedirs --> off
   git_system_enable_homedirs --> off
   httpd_enable_homedirs --> off
   mock_enable_homedirs --> off
   mpd_enable_homedirs --> off
   openvpn_enable_homedirs --> on
   ssh_chroot_rw_homedirs --> off

5. sesearch コマンドを使用すると、選択したブール値が意図するとおりに機能するかどうかを確認できます。次に例を示します。

   $ sesearch -A | grep httpd_enable_homedirs
   …
   allow httpd_suexec_t autofs_t:dir { getattr open search }; [ use_nfs_home_dirs && httpd_enable_homedirs ]:True
   allow httpd_suexec_t autofs_t:dir { getattr open search }; [ use_samba_home_dirs && httpd_enable_homedirs ]:True
   …

6. お客様の状況に合ったブール値がない場合は、状況に合った SELinux タイプを見つけます。sesearch を使用してデフォルトのポリシーから対応するルールを照会することで、ファイルのタイプを見つけることができます。次に例を示します。

   $ sesearch -A -s httpd_t -c file -p read
   …
   allow httpd_t httpd_t:file { append getattr ioctl lock open read write };
   allow httpd_t httpd_tmp_t:file { append create getattr ioctl link lock map open read rename setattr unlink write };
   …

7. 以上の解決策がどれもお客様の状況に当てはまらない場合は、SELinux ポリシーにカスタムルールを追加できます。詳細は、ローカル SELinux ポリシーモジュールの作成 セクションを参照してください。

手順

1. ターミナルで user_selinux(8) man ページを開きます。

   $ man user_selinux

   MANAGED FILES セクションで、お客様の状況に合った属性またはタイプを見つけます。たとえば、user_home_type 属性です。

2. 属性に割り当てられているすべてのタイプをリスト表示するには、-x および -a オプションを指定した seinfo コマンドを使用します。次に例を示します。

   $ seinfo -x -a user_home_type
   
   Type Attributes: 1
      attribute user_home_type;
   …
   	chrome_sandbox_home_t
   	config_home_t
   	cvs_home_t
   	data_home_t
   	dbus_home_t
   	fetchmail_home_t
   	gconf_home_t
   	git_user_content_t
   …

3. 対応するタイプの候補 (この例では data_home_t タイプ) を特定したら、その SELinux マッピングを確認します。

   $ semanage fcontext -l | grep data_home_t
   …
   /root/\.local/share(/.*)?                          all files          system_u:object_r:data_home_t:s0
   …

4. 対応するタイプを、user_u からアクセス可能にするディレクトリー (例: /shared-data) にマップします。

   $ semanage fcontext -a -t data_home_t '/shared-data(/.*)?'

検証

1. 設定したディレクトリーのマッピングを確認します。

   # semanage fcontext -l | grep "shared-data"
   /shared-data(/.*)?                             	all files      	system_u:object_r:data_home_t:s0

2. user_u SELinux ユーザーにマップされた Linux ユーザーとしてログインし、ディレクトリーにアクセスできることを確認します。

手順

1. SELinux がシナリオをブロックしたときに、最初に拒否に関する詳細情報を確認するのは /var/log/audit/audit.log ファイルとなります。Audit ログのクエリーには、ausearch ツールを使用します。アクセスを許可する、または許可しないといった SELinux の決定はキャッシュされ、このキャッシュは AVC (アクセスベクターキャッシュ) として知られています。たとえば、メッセージタイプパラメーターには AVC および USER_AVC の値を使用します。

   # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

   一致するものがない場合は、Audit デーモンが実行しているかどうかを確認します。実行していない場合は、auditd を起動して Audit ログを再確認してから、拒否されたシナリオを繰り返します。

2. auditd が実行中で、ausearch の出力に一致がない場合は、systemd ジャーナルが出力するメッセージを確認してください。

   # journalctl -t setroubleshoot

3. SELinux が有効で、Audit デーモンがシステムで実行していない場合は、dmesg コマンドの出力で特定の SELinux メッセージを検索します。

   # dmesg | grep -i -e type=1300 -e type=1400

4. 以上の 3 つを確認しても、何も見つからない場合もあります。この場合、dontaudit ルールが原因で AVC 拒否を非表示にできます。

   一時的に dontaudit ルールを無効にし、すべての拒否をログに記録できるようにするには、以下のコマンドを実行します。

   # semodule -DB

   以前の手順で、拒否されたシナリオを再実行し、拒否メッセージを取得したら、次のコマンドはポリシーで dontaudit ルールを再度有効にします。

   # semodule -B

5. これまでの 4 つのステップをすべて試し、それでも問題が解決しない場合は、SELinux がシナリオをブロックするかどうかを検討してください。

   • Permissive モードに切り替えます。

     # setenforce 0
     $ getenforce
     Permissive

   • シナリオを繰り返します。

   上記を試しても問題が発生する場合は、SELinux 以外に原因があります。

手順

1. 以下のように、sealert コマンドを実行して、ログに記録されている拒否の詳細をリスト表示します。

   $ sealert -l "*"
   SELinux is preventing /usr/bin/passwd from write access on the file
   /root/test.
   
   *****  Plugin leaks (86.2 confidence) suggests *****************************
   
   If you want to ignore passwd trying to write access the test file,
   because you believe it should not need this access.
   Then you should report this as a bug.
   You can generate a local policy module to dontaudit this access.
   Do
   # ausearch -x /usr/bin/passwd --raw | audit2allow -D -M my-passwd
   # semodule -X 300 -i my-passwd.pp
   
   *****  Plugin catchall (14.7 confidence) suggests **************************
   
   ...
   
   Raw Audit Messages
   type=AVC msg=audit(1553609555.619:127): avc:  denied  { write } for
   pid=4097 comm="passwd" path="/root/test" dev="dm-0" ino=17142697
   scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023
   tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0
   
   ...
   
   Hash: passwd,passwd_t,admin_home_t,file,write

2. 前の手順で取得した出力に明確な提案が含まれていない場合は、以下のコマンドを実行します。

   • 完全パス監査を有効にして、アクセスしたオブジェクトの完全パスを表示し、追加の Linux Audit イベントフィールドが表示されるようにします。

     # auditctl -w /etc/shadow -p w -k shadow-write

   • setroubleshoot キャッシュを削除します。

     # rm -f /var/lib/setroubleshoot/setroubleshoot.xml

   • 問題を再現します。

   • ステップ 1 を繰り返します。

     プロセスが完了したら、完全パスの監査を無効にします。

     # auditctl -W /etc/shadow -p w -k shadow-write

3. sealert が catchall 提案を返すか、audit2allow ツールを使用して新しいルールを追加するように提案した場合は、Audit ログの SELinux 拒否 で説明されている例と問題を一致させます。

手順

1. テキストエディターで新しい .cil を開きます。以下に例を示します。

   # vim <local_module>.cil

   ローカルモジュールをより適切に整理するには、ローカル SELinux ポリシーモジュール名で接頭辞 local_ を使用します。

2. 既知の問題または Red Hat ソリューションからカスタムルールを挿入します。

   重要

   独自のルールを作成しないでください。特定の既知の問題または Red Hat ソリューションで提供されているルールのみを使用します。

   • たとえば、SELinux denies cups-lpd read access to cups.sock in RHEL のソリューションを実装するには、以下の規則を挿入します。

     (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read)))

     このサンプルソリューションは、RHBA-2021:4420 で RHEL 用に永続的に修正されました。したがって、このソリューションの特定の手順は更新済みの RHEL 8 システムおよび 9 システムに影響を与えず、構文のサンプルとしてのみ含まれています。

     2 つの SELinux ルール構文 (Common Intermediate Language (CIL) と m4) のどちらかを使用できます。たとえば、CIL の (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read))) は、m4 の以下と同じになります。

     module local_cupslpd-read-cupssock 1.0;
     
     require {
         type cupsd_var_run_t;
         type cupsd_lpd_t;
         class sock_file read;
     }
     
     #============= cupsd_lpd_t ==============
     allow cupsd_lpd_t cupsd_var_run_t:sock_file read;

3. ファイルを保存してから閉じます。

4. ポリシーモジュールをインストールします。

   # semodule -i <local_module>.cil

   semodule -i を使用して作成したローカルポリシーモジュールを削除する場合は、.cil 接尾辞のないモジュール名を参照してください。ローカルポリシーモジュールを削除するには、semodule -r <local_module> を使用します。

5. ルールに関連するサービスを再起動します。

   # systemctl restart <service-name>

検証

1. SELinux ポリシーにインストールされているローカルモジュールをリスト表示します。

   # semodule -lfull | grep "local_"
   400 local_module  cil

   ローカルモジュールの優先順位は 400 であるため、semodule -lfull | grep -v ^100 コマンドを使用して、その値を使用してリストからそれらをフィルター処理することもできます。

2. 関連する許可ルールを SELinux ポリシーで検索します。

   # sesearch -A --source=<SOURCENAME> --target=<TARGETNAME> --class=<CLASSNAME> --perm=<P1>,<P2>

   <SOURCENAME> はソースの SELinux の種類、<TARGETNAME> はターゲットの SELinux の種類、<CLASSNAME> はセキュリティークラスまたはオブジェクトクラスの名前、そして <P1> と <P2> はルール固有の権限です。

   たとえば、SELinux denies cups-lpd read access to cups.sock in RHEL ソリューションの場合は、以下を行います。

   # sesearch -A --source=cupsd_lpd_t --target=cupsd_var_run_t --class=sock_file --perm=read
   allow cupsd_lpd_t cupsd_var_run_t:sock_file { append getattr open read write };

   最後の行には、read 操作が含まれているはずです。

3. 関連するサービスが SELinux に制限されて実行されていることを確認します。

   1. 関連するサービスに関連するプロセスを特定します。

      $ systemctl status <service-name>

   2. 上記コマンドの出力でリスト表示されたプロセスの SELinux コンテキストを確認します。

      $ ps -efZ | grep <process-name>

4. サービスが SELinux の拒否を引き起こさないことを確認します。

   # ausearch -m AVC -i -ts recent
   <no matches>

   -i オプションは、数値を人間が判読できるテキストに解析します。

手順

1. selinux-policy-mls パッケージをインストールします。

   # yum install selinux-policy-mls

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

   # vi /etc/selinux/config

3. SELinux モードを Enforcing から Permissive に変更し、ターゲットポリシーから MLS に切り替えます。

   SELINUX=permissive
   SELINUXTYPE=mls

   変更を保存し、エディターを終了します。

4. MLS ポリシーを有効にする前に、MLS ラベルでファイルシステム上の各ファイルに再度ラベル付けする必要があります。

   # fixfiles -F onboot
   System will relabel on next boot

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

   # reboot

6. SELinux 拒否を確認します。

   # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent -i

   上記のコマンドはすべてのシナリオに対応していないため、SELinux 拒否の識別、分析、修正のガイダンスは SELinux 関連の問題のトラブルシューティング を参照してください。

7. システムに SELinux に関連する問題がないことを確認したら、/etc/selinux/config で該当するオプションを変更して、SELinux を Enforcing モードに切り替えます。

   SELINUX=enforcing

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

   # reboot

検証

1. SELinux が Enforcing モードで実行されていることを確認します。

   # getenforce
   Enforcing

2. SELinux のステータスが mls の値を返すことを確認します。

   # sestatus | grep mls
   Loaded policy name:             mls

手順

1. 必要に応じて、SELinux ポリシーにエラーを追加しないようにするには、Permissive SELinux モードに切り替えてください。切り替えることでトラブルシューティングが容易になります。

   # setenforce 0

   permissive モードでは、SELinux はアクティブなポリシーを適用せず、Access Vector Cache (AVC) メッセージをログに記録するだけです。このログは、トラブルシューティングやデバッグに使用できます。

2. SELinux ユーザー staff_u のクリアランスの範囲を定義します。たとえば、このコマンドは、クリアランスの範囲を s1 から s15 に、デフォルトのクリアランスレベルを s1 に設定します。

   # semanage user -m -L s1 -r s1-s15 staff_u

3. ユーザーのホームディレクトリー用の SELinux ファイルコンテキスト設定エントリーを生成します。

   # genhomedircon

4. ファイルセキュリティーコンテキストをデフォルトに復元します。

   # restorecon -R -F -v /home/
   Relabeled /home/staff from staff_u:object_r:user_home_dir_t:s0 to staff_u:object_r:user_home_dir_t:s1
   Relabeled /home/staff/.bash_logout from staff_u:object_r:user_home_t:s0 to staff_u:object_r:user_home_t:s1
   Relabeled /home/staff/.bash_profile from staff_u:object_r:user_home_t:s0 to staff_u:object_r:user_home_t:s1
   Relabeled /home/staff/.bashrc from staff_u:object_r:user_home_t:s0 to staff_u:object_r:user_home_t:s1

5. ユーザーにクリアランスレベルを割り当てます。

   # semanage login -m -r s1 example_user

   ここで、s1 は、ユーザーに割り当てられたクリアランスレベルに置き換えます。

6. ユーザーのホームディレクトリーのラベルをユーザーのクリアランスレベルに付け直します。

   # chcon -R -l s1 /home/example_user

7. 必要に応じて、SELinux モードを Permissive に切り替えた場合は、すべてが想定通りに動作することを確認したら、SELinux モードを Enforcing モードに戻します。

   # setenforce 1

検証

1. ユーザーが正しい SELinux ユーザーにマッピングされ、クリアランスレベルが正しく割り当てられていることを確認します。

   # semanage login -l
   Login Name      SELinux User         MLS/MCS Range        Service
   __default__     user_u               s0-s0                *
   example_user    user_u               s1                   *
   …

2. MLS 内のユーザーとしてログインします。

3. ユーザーのセキュリティーレベルが正しく機能していることを確認します。

   警告

   検証に使用するファイルには、設定が間違っており、ユーザーが実際に認証なしにファイルにアクセスできてしまう場合に備え、機密情報を含めないようにしてください。

   1. ユーザーが機密レベルの高いファイルを読み取れないことを確認します。
   2. ユーザーが同じ機密レベルのファイルに書き込めることを確認します。
   3. ユーザーが機密レベルの低いファイルを読み取れることを確認します。

手順

1. セキュアな端末からユーザーとしてログインします。

   セキュアな端末は、、/etc/selinux/mls/contexts/securetty_types ファイルで定義されています。デフォルトでは、コンソールはセキュアな端末ですが、SSH はセキュアではありません。

2. 現在のユーザーのセキュリティーコンテキストを確認します。

   $ id -Z
   user_u:user_r:user_t:s0-s2

   この例では、ユーザーは user_u SELinux ユーザー、user_r ロール、user_t タイプ、s0-s2 の MLS セキュリティーファイルに割り当てられます。

3. 現在のユーザーのセキュリティーコンテキストを確認します。

   $ id -Z
   user_u:user_r:user_t:s1-s2

4. ユーザーのクリアランス範囲内で別のセキュリティークリアランス範囲に切り替えます。

   $ newrole -l s1

   最大が割り当てられた範囲以下の範囲に切り替えることができます。単一レベルの範囲を入力すると、割り当てられた範囲の下限が変更されます。たとえば、範囲が s0-s2 のユーザーとして newrole -l s1 を入力することは、newrole -l s1-s2 を入力することに相当します。

検証

1. 現在のユーザーのセキュリティーコンテキストを確認します。

   $ id -Z
   user_u:user_r:user_t:s1-s2

2. 現在のシェルを終了し、元の範囲で前のシェルに戻ります。

   $ exit

手順

1. オプション: 現在のユーザーのセキュリティーコンテキストを表示します。

   $ id -Z
   user_u:user_r:user_t:s0-s2

2. ユーザーの MLS クリアランス範囲の下位レベルを、ファイルに割り当てるレベルに変更します。

   $ newrole -l s1-s2

3. オプション: 現在のユーザーのセキュリティーコンテキストを表示します。

   $ id -Z
   user_u:user_r:user_t:s1-s2

4. オプション: ファイルのセキュリティーコンテキストを表示します。

   $ ls -Z /path/to/file
   user_u:object_r:user_home_t:s0 /path/to/file

5. ファイルを変更して、ファイルの機密レベルをユーザーのクリアランス範囲の下位レベルに変更します。

   $ touch /path/to/file

   重要

   システムで restorecon コマンドを使用すると、分類レベルはデフォルト値に戻ります。

6. オプション: シェルを終了して、ユーザーの以前のセキュリティー範囲に戻ります。

   $ exit

手順

1. ファイルの区分レベルを確認します。

   # ls -lZ /path/to/file
   -rw-r-----. 1 User1 User1 user_u:object_r:user_home_t:s1 0 12. Feb 10:43 /path/to/file

2. ファイルのデフォルトの区分レベルを変更します。

   # semanage fcontext -a -r s2 /path/to/file

3. ファイルの SELinux コンテキストのラベルを強制的につけ直します。

   # restorecon -F -v /path/to/file
   Relabeled /path/to/file from user_u:object_r:user_home_t:s1 to user_u:object_r:user_home_t:s2

検証

1. ファイルの区分レベルを確認します。

   # ls -lZ /path/to/file
   -rw-r-----. 1 User1 User1 user_u:object_r:user_home_t:s2 0 12. Feb 10:53 /path/to/file

2. オプション: クリアランスが低いユーザーがファイルを読み込めないことを確認します。

   $ cat /path/to/file
   cat: file: Permission denied

手順

1. ユーザー向けに、新しい sudoers ファイルを /etc/sudoers.d ディレクトリーに作成します。

   # visudo -f /etc/sudoers.d/<sec_adm_user>

   sudoers ファイルを整理しておくには、<sec_adm_user> を secadm ロールに割り当てられる Linux ユーザーに置き換えます。

2. /etc/sudoers.d/<sec_adm_user> ファイルに、以下の内容を追加します。

   <sec_adm_user> ALL=(ALL) TYPE=secadm_t ROLE=secadm_r ALL

   この行は、すべてのホスト上の <secadmuser> が、すべてのコマンドを実行することを許可し、デフォルトでユーザーを secadm SELinux タイプとロールにマップします。

3. <sec_adm_user> ユーザーでログインします。

   SELinux コンテキスト (SELinux のユーザー、ロール、タイプで構成) が変更されていることを確認するために、ssh、コンソール、または xdm を使用してログイン します。su および sudo などの他の方法では、SELinux コンテキスト全体を変更することはできません。

4. ユーザーのセキュリティーコンテキストを確認します。

   $ id
   uid=1000(<sec_adm_user>) gid=1000(<sec_adm_user>) groups=1000(<sec_adm_user>) context=staff_u:staff_r:staff_t:s0-s15:c0.c1023

5. root ユーザーの対話型シェルを実行します。

   $ sudo -i
   [sudo] password for <sec_adm_user>:

6. 現在のユーザーのセキュリティーコンテキストを確認します。

   # id
   uid=0(root) gid=0(root) groups=0(root) context=staff_u:secadm_r:secadm_t:s0-s15:c0.c1023

7. ポリシーから sysadm_secadm モジュールを無効にします。

   # semodule -d sysadm_secadm

   重要

   semodule -r コマンドを使用してシステムポリシーモジュールを削除する代わりに、semodule -d コマンドを使用します。semodule -r コマンドは、システムのストレージからモジュールを削除します。これは、selinux-policy-mls パッケージを再インストールしないと、モジュールを再び読み込むことができないことを意味します。

検証

1. secadm ロールに割り当てられたユーザーとして、root ユーザーの対話型シェルで、セキュリティーポリシーデータにアクセスできることを確認します。

   # seinfo -xt secadm_t
   
   Types: 1
      type secadm_t, can_relabelto_shadow_passwords, (…) userdomain;

2. root シェルからログアウトします。

   # logout

3. <sec_adm_user> ユーザーからログアウトします。

   $ logout
   Connection to localhost closed.

4. 現在のセキュリティーコンテキストを表示します。

   # id
   uid=0(root) gid=0(root) groups=0(root) context=root:sysadm_r:sysadm_t:s0-s15:c0.c1023

5. sysadm_secadm モジュールの有効化を試してください。コマンドは失敗するはずです。

   # semodule -e sysadm_secadm
   SELinux:  Could not load policy file /etc/selinux/mls/policy/policy.31:  Permission denied
   /sbin/load_policy:  Can't load policy:  Permission denied
   libsemanage.semanage_reload_policy: load_policy returned error code 2. (No such file or directory).
   SELinux:  Could not load policy file /etc/selinux/mls/policy/policy.31:  Permission denied
   /sbin/load_policy:  Can't load policy:  Permission denied
   libsemanage.semanage_reload_policy: load_policy returned error code 2. (No such file or directory).
   semodule:  Failed!

6. sysadm_t SELinux タイプに関する詳細の表示を試してください。コマンドは失敗するはずです。

   # seinfo -xt sysadm_t
   [Errno 13] Permission denied: '/sys/fs/selinux/policy'

手順

1. 現在の端末タイプを確認します。

   # ls -Z `tty`
   root:object_r:user_devpts_t:s0 /dev/pts/0

   この出力例では、user_devpts_t が現在の端末タイプです。

2. /etc/selinux/mls/contexts/securetty_types ファイルの新しい行に、関連する SELinux タイプを追加します。

3. オプション: SELinux を強制モードに切り替えます。

   # setenforce 1

手順

1. オプション: トラブルシューティングを実施しやすくするために、Permissive モードに切り替えます。

   # setenforce 0

2. ~/local_mlsfilewrite.cil などのテキストエディターで新しい .cil ファイルを開き、以下のカスタムルールを挿入します。

   (typeattributeset mlsfilewrite (_staff_t_))

   staff_t は、別の SELinux タイプに置き換えることができます。ここで SELinux タイプを指定することで、下位レベルのファイルを編集できる SELinux ロールを制御できます。

   ローカルモジュールをより適切に整理するには、ローカル SELinux ポリシーモジュール名で接頭辞 local_ を使用します。

3. ポリシーモジュールをインストールします。

   # semodule -i ~/local_mlsfilewrite.cil

   注記

   ローカルポリシーモジュールを削除するには、semodule -r ~/local_mlsfilewrite を使用します。モジュール名を参照する場合は、接頭辞 .cil なしで参照する必要がある点に注意してください。

4. オプション: 以前に permissive モードに戻した場合は、enforcing モードに戻ります。

   # setenforce 1

検証

1. インストールされている SELinux モジュールのリストでローカルモジュールを検索します。

   # semodule -lfull | grep "local_mls"
   400 local_mlsfilewrite  cil

   ローカルモジュールの優先度は 400 であるため、semodule -lfull | grep -v ^100 コマンドを使用してリスト表示することもできます。

2. カスタムルールで定義されているタイプ (staff_t など) に割り当てられたユーザーとしてログインします。

3. 機密レベルが低いファイルに書き込みを試みます。これにより、ファイルの区分レベルがユーザーのクリアランスレベルまで上昇します。

   重要

   検証に使用するファイルには、設定が間違っており、ユーザーが実際に認証なしにファイルにアクセスできてしまう場合に備え、機密情報を含めないようにしてください。

手順

1. 新しいファイルを作成します (例: local_mcs_user.cil)。

   # vim local_mcs_user.cil

2. 以下のルールを挿入します。

   (typeattributeset mcs_constrained_type (user_t))

3. ポリシーモジュールをインストールします。

   # semodule -i local_mcs_user.cil

手順

1. テキストエディターで /etc/selinux/<selinuxpolicy>/setrans.conf ファイルを編集して、既存のカテゴリーを修正したり、カテゴリーを新たに作成したりできます。お使いの SELinux ポリシーに応じて、<selinuxpolicy> を targeted または mls に置き換えます。以下に例を示します。

   # vi /etc/selinux/targeted/setrans.conf

2. ポリシーの setrans.conf ファイルで、構文 s_<security level>_:c_<category number>_=<category.name> を使用して、シナリオで必要なカテゴリーの組み合わせを定義します。以下に例を示します。

   s0:c0=Marketing
   s0:c1=Finance
   s0:c2=Payroll
   s0:c3=Personnel

   • カテゴリー番号は、c0 から c1023 まで使用できます。
   • targeted ポリシーでは、s0 セキュリティーレベルを使用します。
   • mls ポリシーでは、機密レベルとカテゴリーの組み合わせにラベルを付けることができます。
3. 必要に応じて、setrans.conf ファイル内で、MLS 機密レベルにラベルを付けることもできます。
4. ファイルを保存し、終了します。

5. 変更を有効にするには、MCS 変換サービスを再起動します。

   # systemctl restart mcstrans

手順

1. SELinux ユーザーのセキュリティー範囲を定義します。

   # semanage user -m -rs0:c0,c1-s0:c0.c9 <user_u>

   setrans.conf ファイルで定義されているように、c0 から c1023 までのカテゴリー番号またはカテゴリーラベルを使用します。詳細は、MCS でのカテゴリーラベルの定義 を参照してください。

2. Linux ユーザーに MCS カテゴリーを割り当てます。指定できるのは、関連する SELinux ユーザーに定義された範囲内でのみです。

   # semanage login -m -rs0:c1 <Linux.user1>

   注記

   chcat コマンドを使用して、Linux ユーザーにカテゴリーを追加または削除できます。以下の例では、<category1> を追加し、<Linux.user1> および <Linux.user2> から <category2> を削除します。

   # chcat -l -- +<category1>,-<category2> <Linux.user1>,<Linux.user2>

   -<category> 構文を使用する前に、コマンドラインで -- を指定する必要があります。指定しないと、chcat コマンドは、カテゴリーの削除をコマンドオプションであると誤って解釈します。

検証

1. ファイルのセキュリティーコンテキストを表示して、カテゴリーが正しいことを確認します。

   $ ls -lZ <path/to/file>
   -rw-r--r--  <LinuxUser1> <Group1> root:object_r:user_home_t:_<sensitivity>_:_<category>_ <path/to/file>

   ファイルの特定のセキュリティーコンテキストは異なる場合があります。

2. (必要に応じて) ファイルと同じカテゴリーに割り当てられていない Linux ユーザーとしてログインしたときに、ファイルにアクセスしようとします。

   $ cat <path/to/file>
   cat: <path/to/file>: Permission Denied

手順

1. この手順例では、/var/log/messages ファイルを開いて書き込みを行う簡単なデーモンを準備します。

   1. 新しいファイルを作成して、選択したテキストエディターで開きます。

      $ vi mydaemon.c

   2. 以下のコードを挿入します。

      #include <unistd.h>
      #include <stdio.h>
      
      FILE *f;
      
      int main(void)
      {
      while(1) {
      f = fopen("/var/log/messages","w");
              sleep(5);
              fclose(f);
          }
      }

   3. ファイルをコンパイルします。

      $ gcc -o mydaemon mydaemon.c

   4. デーモンの systemd ユニットファイルを作成します。

      $ vi mydaemon.service
      [Unit]
      Description=Simple testing daemon
      
      [Service]
      Type=simple
      ExecStart=/usr/local/bin/mydaemon
      
      [Install]
      WantedBy=multi-user.target

   5. デーモンをインストールして起動します。

      # cp mydaemon /usr/local/bin/
      # cp mydaemon.service /usr/lib/systemd/system
      # systemctl start mydaemon
      # systemctl status mydaemon
      ● mydaemon.service - Simple testing daemon
         Loaded: loaded (/usr/lib/systemd/system/mydaemon.service; disabled; vendor preset: disabled)
         Active: active (running) since Sat 2020-05-23 16:56:01 CEST; 19s ago
       Main PID: 4117 (mydaemon)
          Tasks: 1
         Memory: 148.0K
         CGroup: /system.slice/mydaemon.service
                 └─4117 /usr/local/bin/mydaemon
      
      May 23 16:56:01 localhost.localdomain systemd[1]: Started Simple testing daemon.

   6. 新しいデーモンが SELinux によって制限されていないことを確認します。

      $ ps -efZ | grep mydaemon
      system_u:system_r:unconfined_service_t:s0 root 4117    1  0 16:56 ?        00:00:00 /usr/local/bin/mydaemon

2. デーモンのカスタムポリシーを生成します。

   $ sepolicy generate --init /usr/local/bin/mydaemon
   Created the following files:
   /home/example.user/mysepol/mydaemon.te # Type Enforcement file
   /home/example.user/mysepol/mydaemon.if # Interface file
   /home/example.user/mysepol/mydaemon.fc # File Contexts file
   /home/example.user/mysepol/mydaemon_selinux.spec # Spec file
   /home/example.user/mysepol/mydaemon.sh # Setup Script

3. 直前のコマンドで作成した設定スクリプトを使用して、新しいポリシーモジュールでシステムポリシーを再構築します。

   # ./mydaemon.sh
   Building and Loading Policy
   + make -f /usr/share/selinux/devel/Makefile mydaemon.pp
   Compiling targeted mydaemon module
   Creating targeted mydaemon.pp policy package
   rm tmp/mydaemon.mod.fc tmp/mydaemon.mod
   + /usr/sbin/semodule -i mydaemon.pp
   ...

   restorecon コマンドを使用して、設定スクリプトがファイルシステムの対応する部分の再ラベル付けを行うことに注意してください。

   restorecon -v /usr/local/bin/mydaemon /usr/lib/systemd/system

4. デーモンを再起動して、SELinux が制限のあるデーモンを実行していることを確認します。

   # systemctl restart mydaemon
   $ ps -efZ | grep mydaemon
   system_u:system_r:mydaemon_t:s0 root        8150       1  0 17:18 ?        00:00:00 /usr/local/bin/mydaemon

5. デーモンは SELinux によって制限されているため、SELinux はこのデーモンが /var/log/messages にアクセスできないようにします。対応する拒否メッセージを表示します。

   # ausearch -m AVC -ts recent
   ...
   type=AVC msg=audit(1590247112.719:5935): avc:  denied  { open } for  pid=8150 comm="mydaemon" path="/var/log/messages" dev="dm-0" ino=2430831 scontext=system_u:system_r:mydaemon_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file permissive=1
   ...

6. sealert ツールを使用して追加情報を取得することもできます。

   $ sealert -l "*"
   SELinux is preventing mydaemon from open access on the file /var/log/messages.
   
   *****  Plugin catchall (100. confidence) suggests   **************************
   
   If you believe that mydaemon should be allowed open access on the messages file by default.
   Then you should report this as a bug.
   You can generate a local policy module to allow this access.
   Do allow this access for now by executing:
   # ausearch -c 'mydaemon' --raw | audit2allow -M my-mydaemon
   # semodule -X 300 -i my-mydaemon.pp
   
   Additional Information:
   Source Context                system_u:system_r:mydaemon_t:s0
   Target Context                unconfined_u:object_r:var_log_t:s0
   Target Objects                /var/log/messages [ file ]
   Source                        mydaemon
   …

7. audit2allow ツールを使用して、変更を提案します。

   $ ausearch -m AVC -ts recent | audit2allow -R
   
   require {
   	type mydaemon_t;
   }
   
   #============= mydaemon_t ==============
   logging_write_generic_logs(mydaemon_t)

8. audit2allow が提案するルールは特定のケースでは正しくない可能性があるため、出力の一部のみを使用して対応するポリシーインターフェイスを見つけます。macro-expander ツールを使用して logging_write_generic_logs (mydaemon_t) マクロを検査し、マクロが提供するすべての許可ルールを確認します。

   $ macro-expander "logging_write_generic_logs(mydaemon_t)"
   allow mydaemon_t var_t:dir { getattr search open };
   allow mydaemon_t var_log_t:dir { getattr search open read lock ioctl };
   allow mydaemon_t var_log_t:dir { getattr search open };
   allow mydaemon_t var_log_t:file { open { getattr write append lock ioctl } };
   allow mydaemon_t var_log_t:dir { getattr search open };
   allow mydaemon_t var_log_t:lnk_file { getattr read };

9. ここでは、提案されたインターフェイスを使用できます。このインターフェイスは、ログファイルとその親ディレクトリーへの読み取りおよび書き込みアクセスのみを提供するためです。Type Enforcement ファイルに対応するルールを追加します。

   $ echo "logging_write_generic_logs(mydaemon_t)" >> mydaemon.te

   または、インターフェイスを使用する代わりに、このルールを追加することもできます。

   $ echo "allow mydaemon_t var_log_t:file { open write getattr };" >> mydaemon.te

10. ポリシーを再インストールします。

    # ./mydaemon.sh
    Building and Loading Policy
    + make -f /usr/share/selinux/devel/Makefile mydaemon.pp
    Compiling targeted mydaemon module
    Creating targeted mydaemon.pp policy package
    rm tmp/mydaemon.mod.fc tmp/mydaemon.mod
    + /usr/sbin/semodule -i mydaemon.pp
    ...

検証

1. アプリケーションが SELinux によって制限されて実行されていることを確認します。以下に例を示します。

   $ ps -efZ | grep mydaemon
   system_u:system_r:mydaemon_t:s0 root        8150       1  0 17:18 ?        00:00:00 /usr/local/bin/mydaemon

2. カスタムアプリケーションが SELinux 拒否を生じさせないことを確認します。

   # ausearch -m AVC -ts recent
   <no matches>

1. JSON 形式のコンテナー仕様ファイルを解析する。
2. 最初の部分の結果に基づいて適切な許可ルールを見つける。
3. 最終的な SELinux ポリシーを生成する。

手順

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

   # yum install -y udica

   udica を含むコンテナーソフトウェアパッケージセットを提供する container-tools モジュールをインストールします。

   # yum module install -y container-tools

2. /home ディレクトリーを読み取り権限でマウントする ubi8 コンテナーと、読み取りおよび書き込みの権限で /var/spool ディレクトリーをマウントします。コンテナーはポート 21 を公開します。

   # podman run --env container=podman -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it ubi8 bash

   コンテナーは、SELinux のタイプが container_t で実行されることに注意してください。このタイプは、SELinux ポリシー内のすべてのコンテナーの汎用ドメインであり、シナリオに対して厳密すぎるか緩すぎる可能性があります。

3. 新しいターミナルを開き、podman ps コマンドを入力して、コンテナーの ID を取得します。

   # podman ps
   CONTAINER ID   IMAGE                                   COMMAND   CREATED          STATUS              PORTS   NAMES
   37a3635afb8f   registry.access.redhat.com/ubi8:latest  bash      15 minutes ago   Up 15 minutes ago           heuristic_lewin

4. コンテナーの JSON ファイルを作成し、udica を使用して JSON ファイルの情報に基づいてポリシーモジュールを作成します。

   # podman inspect 37a3635afb8f > container.json
   # udica -j container.json my_container
   Policy my_container with container id 37a3635afb8f created!
   […]

   または、次のようになります。

   # podman inspect 37a3635afb8f | udica my_container
   Policy my_container with container id 37a3635afb8f created!
   
   Please load these modules using:
   # semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}
   
   Restart the container with: "--security-opt label=type:my_container.process" parameter

5. 前の手順の udica の出力で提案されているように、ポリシーモジュールを読み込みます。

   # semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}

6. コンテナーを停止し、--security-opt label=type:my_container.process オプションを使用して再起動します。

   # podman stop 37a3635afb8f
   # podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it ubi8 bash

検証

1. コンテナーが、my_container.process タイプで実行されることを確認します。

   # ps -efZ | grep my_container.process
   unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 root 2275 434  1 13:49 pts/1 00:00:00 podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it ubi8 bash
   system_u:system_r:my_container.process:s0:c270,c963 root 2317 2305  0 13:49 pts/0 00:00:00 bash

2. SELinux が、マウントポイント /home および /var/spool へのアクセスを許可していることを確認します。

   [root@37a3635afb8f /]# cd /home
   [root@37a3635afb8f home]# ls
   username
   [root@37a3635afb8f ~]# cd /var/spool/
   [root@37a3635afb8f spool]# touch test
   [root@37a3635afb8f spool]#

3. SELinux がポート 21 へのバインドのみを許可していることを確認します。

   [root@37a3635afb8f /]# yum install nmap-ncat
   [root@37a3635afb8f /]# nc -lvp 21
   …
   Ncat: Listening on :::21
   Ncat: Listening on 0.0.0.0:21
   ^C
   [root@37a3635afb8f /]# nc -lvp 80
   …
   Ncat: bind to :::80: Permission denied. QUITTING.

手順

1. Playbook を準備します。ゼロから準備するか、rhel-system-roles パッケージの一部としてインストールされたサンプル Playbook を変更してください。

   # cp /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml <my-selinux-playbook.yml>
   # vi <my-selinux-playbook.yml>

2. シナリオに合わせて Playbook の内容を変更します。たとえば、次の部分では、システムが SELinux モジュール selinux-local-1.pp をインストールして有効にします。

   selinux_modules:
   - { path: "selinux-local-1.pp", priority: "400" }

3. 変更を保存し、テキストエディターを終了します。

4. Playbook の構文を検証します。

   $ ansible-playbook <my-selinux-playbook.yml> --syntax-check

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

5. Playbook を実行します。

   $ ansible-playbook <my-selinux-playbook.yml>

手順

1. RHEL 8 Web コンソールにログインします。

   詳細は、Web コンソールへのログイン を参照してください。

2. SELinux をクリックします。

3. View the automation script をクリックします。

   生成されたスクリプトを含むウィンドウが開きます。シェルスクリプトと Ansible Playbook の生成オプションタブ間を移動できます。

   

4. Copy to clipboard ボタンをクリックし、スクリプトまたは Playbook を選択して適用します。

手順

1. 検証された SELinux 設定をエクスポートします。

   # semanage export -f ./my-selinux-settings.mod

2. 設定を含むファイルを新しいシステムにコピーします。

   # scp ./my-selinux-settings.mod new-system-hostname:

3. 新しいシステムにログインします。

   $ ssh root@new-system-hostname

4. 新しいシステムに設定をインポートします。

   new-system-hostname# semanage import -f ./my-selinux-settings.mod