newrole -r role_r -t domain_t (there is usually only a single domain allowed for a given role, the -t parameter can thus often be left out). This command authenticates you by asking you to type your password. This feature forbids programs to automatically switch roles. Such changes can only happen if they are explicitly allowed in the SELinux policy.
ssh は ssh_exec_t でラベリングされています。ssh プログラムが起動すると ssh プログラムは ssh_t SELinux ドメインに自動的に切り替わります)。この自動 SELinux ドメイン遷移メカニズムによって、それぞれのプログラムに対して必要な権限だけを認めることが可能です。これが SELinux の基本原則です。
apt install selinux-basics selinux-policy-default auditd command will automatically install the packages required to configure an SELinux system.
unconfined モジュールを無効化しなければいけません (モジュール管理に関してはこの節でさらに詳しく説明しています)。
fixfiles relabel を使って手作業で開始しなければいけません。
selinux=1 security=selinux パラメータを Linux カーネルに追加する必要があります。audit=1 パラメータを指定した場合、SELinux のログ記録が有効化され、すべての拒否された操作が記録されます。最後に enforcing=1 パラメータを指定した場合、ルールをアプリケーションに強制します。enforcing=1 パラメータを指定しなかった場合、SELinux はデフォルトの permissive モードで動作します。permissive モードの場合、拒否された操作はログ記録され、実行されます。このため、GRUB ブートローダ設定ファイルを変更して必要なパラメータを追加するべきです。これを簡単に行うには、/etc/default/grub の中の GRUB_CMDLINE_LINUX 変数に必要なパラメータを追加し、update-grub を実行します。SELinux は再起動後に動作状態になります。
selinux-activate スクリプトを使うことで、GRUB ブートローダ設定ファイルに対する変更操作が自動化され、次回起動時にラベリングが強制されます (強制的にラベリングすることで SELinux がまだ動作していなかった時とラベリングの実行中にラベリングされていないファイルが新しく作成されることを避けることが可能です)。この点は注目に値します。
semodule コマンドです。さらに、管理者はそれぞれのユーザに与える SELinux ロールを定義する能力を持っていなければいけません。これは semanage を使って行います。
semodule と semanage コマンドは /etc/selinux/default/ に保存されている現在の SELinux 設定を変更するために使われます。/etc/ に配置されている SELinux 以外の設定ファイルと異なり、SELinux の設定ファイルはすべて手作業で修正されなければいけません。管理者は SELinux 設定ファイルを編集するために設計されたプログラムを使うべきです。
/usr/share/selinux/default/ ディレクトリに保存されています。現在の設定の中で SELinux モジュールの 1 つをインストールするには、semodule -i module.pp.bz2 を使うべきです。pp.bz2 拡張子は bzip2 で圧縮されたポリシーパッケージを意味しています。
semodule -r module を使います。最後に、semodule -l コマンドは現在インストールされているモジュールとそのバージョンをリストします。モジュールを選択的に有効化するには semodule -e、無効化するには semodule -d を使います。
#semodule -i /usr/share/selinux/default/abrt.pp.bz2libsemanage.semanage_direct_install_info: abrt module will be disabled after install as there is a disabled instance of this module present in the system. #semodule -laccountsd acct [...]#semodule -e abrt#semodule -d accountsd#semodule -labrt acct [...]#semodule -r abrtlibsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.
semodule は -n オプションを付けない限り、すぐさま新しい設定を読み込みます。semodule プログラムがデフォルトで現在の設定に対して操作を行う点は注目に値します (現在の設定は /etc/selinux/config 内の SELINUXTYPE 変数によって表されます)。しかし -s オプションを使えば、他の設定に対して操作を行うことも可能です。
semanage コマンドを使えば、2 種類 (Unix ログイン名から SELinux ユーザ名へ、SELinux ユーザ名から SELinux ロールへ) の対応付けを設定することが可能です。
-a to add, -d to delete, -m to modify, -l to list, and -t to indicate a type (or domain).
semanage login -l は Unix ログイン名と SELinux ユーザ名の現在の対応付けをリストします。明確なエントリを設定されていない Unix ログイン名を持つユーザは __default__ という Unix ログイン名に対応する SELinux ユーザ名を割り当てられます。semanage login -a -s user_u user コマンドを使うことで、user で指定した Unix ログイン名を持つユーザに user_u で指定した SELinux ユーザ名を割り当てます。最後に、semanage login -d user は user で指定した Unix ログイン名を持つユーザに関連付けられたエントリを削除します。
#semanage login -a -s user_u rhertzog#semanage login -lLogin Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * rhertzog user_u s0 * root unconfined_u s0-s0:c0.c1023 * #semanage login -d rhertzog
semanage user -l は SELinux ユーザ名と許可された SELinux ロールの対応付けをリストします。新しい SELinux ユーザ名を追加する場合、SELinux ユーザ名に対応する SELinux ロールと、個人ファイル (/home/user/*) に SELinux タイプを割り当てるために使われるラベリングプレフィックスが必要になります。このプレフィックスは user、staff、sysadm のどれか 1 つを選ばなければいけません。「staff」プレフィックスを選んだ場合、ファイルの SELinux タイプは「staff_home_dir_t」になります。新しい SELinux ユーザ名を作成するには semanage user -a -R roles -P prefix identity を使います。最後に、SELinux ユーザ名を削除するには semanage user -d identity を使います。
#semanage user -a -R 'staff_r user_r' -P staff test_u#semanage user -lLabeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r system_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r test_u staff s0 s0 staff_r user_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r #semanage user -d test_u
/srv/www/ ファイル階層内のファイルを読むことを許可する場合、semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" を実行し、その後 restorecon -R /srv/www/ を実行します。semanage fcontext -a で新しいラベリングルールを登録し、restorecon で現在のラベリングルールに基づいてファイルの SELinux タイプを再設定します。
semanage port -m -t http_port_t -p tcp 8080 を実行します。
getsebool utility can be used to inspect those options (getsebool boolean displays one option, and getsebool -a them all). The setsebool boolean value command changes the current value of a Boolean option. The -P option makes the change permanent, it means that the new value becomes the default and will be kept across reboots. The example below grants web servers an access to home directories (this is useful when users have personal websites in ~/public_html/).
#getsebool httpd_enable_homedirshttpd_enable_homedirs --> off #setsebool -P httpd_enable_homedirs on#getsebool httpd_enable_homedirshttpd_enable_homedirs --> on
/usr/share/doc/selinux-policy-doc/html/) と新しいモジュールを作成するためのテンプレートとして使えるサンプルファイルが含まれます。これらのファイルをインストールし、さらにしっかりと勉強してください。
$cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile$cp /usr/share/doc/selinux-policy-doc/example.fc ./$cp /usr/share/doc/selinux-policy-doc/example.if ./$cp /usr/share/doc/selinux-policy-doc/example.te ./
.te ファイルは最も重要なファイルです。.te ファイルがルールを定義します。.fc ファイルは「ファイルコンテキスト」を定義します。「ファイルコンテキスト」はこのモジュールに関連するファイルに割り当てる SELinux タイプを意味します。.fc ファイルに含まれるデータはファイルのラベリング中に使われます。最後に、.if ファイルはモジュールのインターフェースを定義します。つまり、モジュールのインターフェースは一連の「公開関数」で、他のモジュールはこの関数を使ってここで作成されたモジュールと情報をやり取りします。
.fc ファイルの構造を十分に理解することが可能です。複数のファイルおよび完全なディレクトリツリーに対して同じセキュリティコンテキストを割り当てるために、正規表現を使うことが可能です。
myapp_domtrans」) はアプリケーションを実行できるユーザを制御します。2 番目のインターフェース (「myapp_read_log」) はアプリケーションのログファイルに対する読み込み権限を制御します。
.te ファイルに組み込むことが可能な有効なルール群を生成しなければいけません。そんなわけで、管理者は (gen_require マクロを使って) 使用するすべての SELinux タイプを宣言し、権限を取得するために標準的な指示文を使うべきです。しかしながら、他のモジュールが提供するインターフェースを使うことが可能な点に注意してください。次の節では、これらの権限を表現する方法についてより詳しく説明します。
例 14.3 example.if ファイル
## <summary>Myapp example policy</summary>
## <desc>
## <p>
## More descriptive text about myapp. The desc
## tag can also use p, ul, and ol
## html tags for formatting.
## </p>
## <p>
## This policy supports the following myapp features:
## <ul>
## <li>Feature A</li>
## <li>Feature B</li>
## <li>Feature C</li>
## </ul>
## </p>
## </desc>
#
########################################
## <summary>
## Execute a domain transition to run myapp.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition.
## </summary>
## </param>
#
interface(`myapp_domtrans',`
gen_require(`
type myapp_t, myapp_exec_t;
')
domtrans_pattern($1,myapp_exec_t,myapp_t)
')
########################################
## <summary>
## Read myapp log files.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to read the log files.
## </summary>
## </param>
#
interface(`myapp_read_log',`
gen_require(`
type myapp_log_t;
')
logging_search_logs($1)
allow $1 myapp_log_t:file read_file_perms;
')
example.te を見てみましょう。
policy_module(example,1.0.0)# a non-base module name must match the file name ######################################## # # Declarations # type myapp_t;
type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t)
type myapp_log_t; logging_log_file(myapp_log_t)
type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms };
allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)
|
モジュールは名前とバージョン番号で識別されます。policy_module マクロは必須です。
|
|
モジュールによって新しい SELinux タイプが導入される場合、type 文を使って新しい SELinux タイプを必ず宣言してください。多くの無駄な権限を与えるのでなく、必要な SELinux タイプをすべて作成してください。遠慮はいりません。
|
|
ここでは domain_type および domain_entry_file インターフェースを使って、myapp_exec_t とラベリングされた実行ファイルによって使われるプロセスの SELinux ドメインとして myapp_t SELinux タイプを定義しています。こうすることで、暗黙のうちにオブジェクトに exec_type 属性が追加されます。このおかげで、他のモジュールは myapp_exec_t とラベリングされたプログラムを実行する権限を取得することが可能になります。たとえば userdomain モジュールを使うことで、user_t、staff_t、sysadm_t SELinux ドメインを持つプロセスが自分を実行することが可能になります。他の閉じ込められたアプリケーションの SELinux ドメインは、その SELinux ドメインに割り当てられたルールが同様の権限を取得しない限り (たとえば dpkg_t SELinux ドメインを持つ dpkg がこの場合に相当します)、myapp_exec_t とラベリングされたプログラムを実行する権限を持ちません。
|
| logging_log_file is an interface provided by the reference policy. It indicates that files labeled with the given type are log files which ought to benefit from the associated rules (for example, granting rights to logrotate so that it can manipulate them).
|
| allow 指示文は操作を許可するために使われる基本的な指示文です。1 番目のパラメータはこの操作を実行することを許されたプロセスの SELinux ドメインです。2 番目のパラメータは 1 番目のパラメータで指定した SELinux ドメインのプロセスが操作することが可能なオブジェクトを定義します。2 番目のパラメータは「type:class」の形で定義します。ここで type は SELinux タイプで class はオブジェクトの種類 (ファイル、ディレクトリ、ソケット、名前付きパイプなど) です。最後に、3 番目のパラメータはパーミッション (許可された操作) を表現します。
パーミッションは許可された操作の一式として定義され、以下のテンプレートに従います。すなわち { operation1 operation2 } です。しかしながら、最も役に立つパーミッションを表すマクロを使うことも可能です。/usr/share/selinux/devel/include/support/obj_perm_sets.spt には、最も役に立つパーミッションのマクロが説明されています。
The following web page provides a relatively exhaustive list of object classes, and permissions that can be granted.
|
avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1表 14.1 SELinux ログエントリの解析
| メッセージ | 説明 |
|---|---|
avc: denied | 操作が拒否されました。 |
{ read write } | この操作には read と write パーミッションが必要です。 |
pid=1876 | PID 1876 のプロセスがこの操作を実行しました (または実行を試行しました)。 |
comm="syslogd" | プロセスは syslogd プログラムのインスタンスです。 |
name="xconsole" | 対象のオブジェクトは xconsole と名付けられました。場合によってはこれの代わりにフルパスを含む「path」変数が設定されていることもあります。 |
dev=tmpfs | The device hosting the target object is a tmpfs (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example, “sda3”). |
ino=5510 | オブジェクトは inode 番号 5510 で識別されています。 |
scontext=system_u:system_r:syslogd_t:s0 | これは操作を実行したプロセスのセキュリティコンテキストです。 |
tcontext=system_u:object_r:device_t:s0 | これは対象オブジェクトのセキュリティコンテキストです。 |
tclass=fifo_file | 対象オブジェクトは FIFO ファイルです。 |
allow syslogd_t device_t:fifo_file { read write }. This process can be automated, and it is exactly what the audit2allow command (of the policycoreutils package) offers. This approach is only useful if the various objects are already correctly labeled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “dontaudit” rule to avoid the log entry despite the effective denial.
example.if, example.fc, and example.te) match your expectations for the new rules, rename them to myapp.extension and run make NAME=devel to generate a module in the myapp.pp file (you can immediately load it with semodule -i myapp.pp). If several modules are defined, make will create all the corresponding .pp files.