手順

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 モードに切り替えてください。これにより、ラベルのないファイルがシステムに含まれている場合に、システムが起動に失敗することを防ぎます。詳細は、RHBZ#2021835 を参照してください。

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

検証

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

   $ getenforce
   Enforcing

手順

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. 再起動したら、getenforce コマンドが Disabled を返すことを確認します。

   $ getenforce
   Disabled

手順

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. 新しいユーザーを作成し、そのユーザーを wheel ユーザーグループに追加し、そのユーザーを SELinux ユーザー sysadm_u にマッピングします。

   # adduser -G wheel -Z sysadm_u example.user

3. 必要に応じて、既存のユーザーを SELinux ユーザー sysadm_u にマッピングし、そのユーザーを wheel ユーザーグループに追加します。

   # usermod -G wheel -Z sysadm_u 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. 新規ユーザーを作成し、そのユーザーを wheel ユーザーグループに追加し、そのユーザーを SELinux ユーザー staff_u にマッピングします。

   # adduser -G wheel -Z staff_u example.user

2. 必要に応じて、既存のユーザーを SELinux ユーザー staff_u にマッピングし、そのユーザーを wheel ユーザーグループに追加します。

   # usermod -G wheel -Z staff_u 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 がシナリオをブロックしたときに、最初に拒否に関する詳細情報を確認するのは /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. 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 はアクティブなポリシーを有効せず、アクセスベクターキャッシュ (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 までのカテゴリー番号またはカテゴリーラベルを使用します。詳細は、Defining category labels in 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 が提案するルールは特定のケースでは正しくない可能性があるため、出力の一部のみを使用して対応するポリシーインターフェイスを見つけます。

   $ grep -r "logging_write_generic_logs" /usr/share/selinux/devel/include/ | grep .if
   /usr/share/selinux/devel/include/system/logging.if:interface(`logging_write_generic_logs',`

9. インターフェイスの定義を確認します。

   $ cat /usr/share/selinux/devel/include/system/logging.if
   ...
   interface(`logging_write_generic_logs',`
           gen_require(`
                   type var_log_t;
           ')
   
           files_search_var($1)
           allow $1 var_log_t:dir list_dir_perms;
           write_files_pattern($1, var_log_t, var_log_t)
   ')
   ...

10. この場合は、推奨されるインターフェイスを使用できます。Type Enforcement ファイルに対応するルールを追加します。

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

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

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

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

    # ./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. テキストエディターで新しい .cil を開きます。以下に例を示します。

   # vim <local_module>.cil

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

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

   重要

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

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

   注記

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

   (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read)))

   2 つの SELinux ルール構文 CIL (Common Intermediate Language) および 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 -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. host1、host2 および host3 システムで Playbook を実行します。

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

手順

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