MochiuWiki : SUSE, EC, PCB

「設定 - SELinux」の版間の差分

📢 Webサイト閉鎖と移転のお知らせ
このWebサイトは2026年9月に閉鎖いたします。
新しい記事は移転先で追加しております。（旧サイトでは記事を追加しておりません）

← 古い編集新しい編集 →
ビジュアルウィキテキスト
259行目: 259行目:
<br><br>
<br><br>


== ポリシーモジュールファイル (TEファイル) のシンタックス ==
== ポリシーモジュールファイル (TEファイル) ==
ポリシーモジュールファイル (TEファイル) を作成することにより、特定のソフトウェアやサービスに対するカスタムポリシーを作成できる。<br>
ポリシーモジュールファイル (TEファイル) を作成することにより、特定のソフトウェアやサービスに対するカスタムポリシーを作成できる。<br>
<br>
以下に示す要素を組み合わせて、特定のアプリケーションやサービスに対するSELinuxポリシーモジュールを作成することができる。<br>
以下のセクションに示す要素を組み合わせて、特定のアプリケーションやサービスに対するSELinuxポリシーモジュールを作成することができる。<br>
<br>
<br>
==== モジュール宣言 ====
==== モジュール宣言 ====
ポリシーパッケージの名前とバージョンを定義する。<br>
ポリシーパッケージの名前とバージョンを定義する。<br>
これは、TEファイルの最初に記述する必要がある。<br>
これは、TEファイルの最初に記述する必要がある。<br>
<br>
policy_moduleマクロを使用すると、自動的にrequire文が追加され、system_rロール、全てのカーネルクラスとパーミッション・オプションでMLS / MCS情報 (sensitivityおよびcategoryステートメント) が含まれる。<br>
<br>
<br>
* モジュール名
* モジュール名
*: ポリシーパッケージの名前
*: ポリシーパッケージの名前
*: モジュールレイヤー内で一意である必要がある
* バージョン
* バージョン
*: ポリシーの更新管理に使用される。
*: ポリシーの更新管理に使用される
*: M.m.m形式 (Mはメジャーバージョン、mはマイナーバージョン)
<br>
<br>
  policy_module(<モジュール名>, <バージョン>)
  policy_module(<モジュール名>, <バージョン>)
278行目: 281行目:
   
   
  例:
  例:
  policy_module(myapp, 1.0)
  policy_module(myapp, 1.0.0)
<br>
<br>
==== タイプ定義 ====
==== タイプ定義 ====
セキュリティコンテキストの一部となるタイプを定義する。<br>
セキュリティコンテキストの一部となるタイプを定義する。<br>
288行目: 290行目:
*: 一般的に、プロセス用のタイプ (_t)、実行ファイル用のタイプ (_exec_t)、データ用のタイプ (_data_t) 等を定義する。
*: 一般的に、プロセス用のタイプ (_t)、実行ファイル用のタイプ (_exec_t)、データ用のタイプ (_data_t) 等を定義する。
*: タイプ名は、アンダースコアで区切られた意味のある名前にすること。
*: タイプ名は、アンダースコアで区切られた意味のある名前にすること。
*: タイプ識別子は、全て _t で終わることが慣例である。(強制ではない)
* エイリアス
*: オプションでエイリアスを定義できる。
*: 複数のエイリアスはスペース区切りで中括弧で囲む。
* 属性
*: オプションで事前に宣言された属性を関連付けできる。
*: 複数の属性はカンマ区切りで指定する。
<br>
<br>
  type <タイプ名>;
  type <タイプ名>;
type <タイプ名> alias <エイリアス名>;
type <タイプ名>, <属性名>;
type <タイプ名> alias <エイリアス名>, <属性名>;
   
   
  例:
  例:
295行目: 307行目:
  type myapp_exec_t;
  type myapp_exec_t;
  type myapp_data_t;
  type myapp_data_t;
type myapp_log_t alias myapp_log_file_t;
type httpd_t, domain, daemon;
<br>
==== 属性定義 ====
複数のタイプをグループ化するための属性を定義する。<br>
<br>
* 属性名
*: 複数のタイプをグループ化するために使用される
*: これにより、複数のタイプに対して1度にルールを適用できる
*: 例えば、全てのネットワークデーモンに共通のルールを適用する場合等に便利である
*: 属性識別子は、タイプと同じ名前空間を共有する
*: 慣例として、属性は _t 以外で終わることでタイプと区別される
<br>
attribute <属性名>;
例:
attribute domain;
attribute daemon;
attribute file_type;
<br>
==== タイプ属性の割り当て ====
事前に宣言されたタイプを、事前に宣言された属性に関連付ける。<br>
<br>
typeattribute <タイプ名> <属性名> [, <属性名>];
例:
attribute domain;
attribute daemon;
type myapp_t;
typeattribute myapp_t domain, daemon;
<br>
<br>
==== ドメイン遷移ルール ====
==== ドメイン遷移ルール ====
プロセスのドメイン変更を自動化する。<br>
プロセスのドメイン変更を定義する。<br>
<br>
<br>
===== type_transitionルール =====
このルールにより、特定のタイプの実行ファイルが実行された時に、プロセスのドメインが自動的に変更される。<br>
このルールにより、特定のタイプの実行ファイルが実行された時に、プロセスのドメインが自動的に変更される。<br>
<br>
以下の例では、unconfined_tドメインのプロセスがmyapp_exec_tタイプの実行ファイルを実行する時、新しいプロセスはmyapp_tドメインで動作する。<br>
以下の例では、unconfined_tドメインのプロセスがmyapp_exec_tタイプの実行ファイルを実行する時、新しいプロセスはmyapp_tドメインで動作する。<br>
<br>
<br>
  domain_auto_trans(<ソースドメイン>, <実行ファイルタイプ>, <ターゲットドメイン>)
  type_transition <ソースタイプ> <ターゲットタイプ>:<クラス> <デフォルトタイプ>;
# ファイル名遷移 (ポリシーバージョン25以降)
type_transition <ソースタイプ> <ターゲットタイプ>:<クラス> <デフォルトタイプ> <オブジェクト名>;
   
   
  例:
  例:
  domain_auto_trans(unconfined_t, myapp_exec_t, myapp_t)
  type_transition unconfined_t myapp_exec_t:process myapp_t;
# ファイル名遷移の例
type_transition unconfined_t etc_t:file system_conf_t eric;
<br>
type_transitionルールは、以下に示す3つのallowルールとともに使用される必要がある。<br>
* ソースドメインがターゲットタイプに対してtransitionパーミッションを持つ。
* ソースドメインが実行ファイルタイプに対してread、execute、getattr等のパーミッションを持つ。
* デフォルトドメインが実行ファイルタイプに対してentrypointパーミッションを持つ。
<br>
<u>※注意</u><br>
<u>Reference Policyでは、domain_auto_transマクロがこれらのルールを自動的に生成する。</u><br>
<br>
===== type_changeルール =====
ユーザ空間のSELinux対応アプリケーションがオブジェクトのラベルを変更する時に使用される。<br>
これらのアプリケーションは、security_compute_relabel(3) と ポリシー内のtype_changeルールを使用して、適用すべき新しいコンテキストを決定する。<br>
<br>
type_change <ソースタイプ> <ターゲットタイプ>:<クラス> <変更後タイプ>;
例:
type_change auditadm_t sysadm_devpts_t:chr_file auditadm_devpts_t;
type_change staff_t server_ptynode:chr_file staff_devpts_t;
<br>
===== type_memberルール =====
SELinux対応アプリケーションがオブジェクトの新しいポリインスタンス化されたラベルを定義する時に使用される。<br>
これらのアプリケーションは、avc_compute_member(3) または security_compute_member(3)とポリシー内のtype_memberルールを使用して、適用すべきコンテキストを決定する。<br>
<br>
type_member <ソースタイプ> <ターゲットタイプ>:<クラス> <メンバータイプ>;
例:
type_member sysadm_t user_home_dir_t:dir user_home_dir_t;
<br>
<br>
==== allowルール ====
==== allowルール ====
315行目: 390行目:
* パーミッション
* パーミッション
*: read、write、execute等の操作を指定する。
*: read、write、execute等の操作を指定する。
*: ワイルドカード演算子 (*) は、そのオブジェクトクラスのすべてのパーミッションを指定する。
*: 補完演算子 (~) は、明示的にリストされたパーミッション以外のすべてのパーミッションを指定する。
* self キーワード
*: ターゲットタイプにselfを指定すると、ソースタイプと同じタイプを意味する。
<br>
<br>
  allow <ソースタイプ> <ターゲットタイプ>:<クラス> { <パーミッション> };
  allow <ソースタイプ> <ターゲットタイプ>:<クラス> { <パーミッション> };
320行目: 399行目:
  例:
  例:
  allow myapp_t myapp_data_t:file { read write getattr };
  allow myapp_t myapp_data_t:file { read write getattr };
allow kernel_t filesystem_type:filesystem mount;
allow staff_t self:capability { setgid chown fowner };
# ワイルドカード演算子の例
allow bootloader_t system_dbusd_t:dbus *;
# 補完演算子の例
allow files_unconfined_type file_type:{ file chr_file } ~execmod;
<br>
==== auditallowルール ====
イベントを監査記録として記録する。<br>
監査目的で有用な場合に使用する。<br>
<br>
このルールはイベントを監査するのみであり、アクセスを許可するにはallowルールが依然として必要である。<br>
<br>
auditallow <ソースタイプ> <ターゲットタイプ>:<クラス> { <パーミッション> };
例:
auditallow ada_t self:process execstack;
<br>
==== dontauditルール ====
拒否メッセージの監査を停止する。<br>
このイベントが常に発生することが既知であり、実際の問題を引き起こさない場合に使用する。<br>
<br>
これにより、既知のイベントを除外することで監査ログの管理を支援する。<br>
<br>
dontaudit <ソースタイプ> <ターゲットタイプ>:<クラス> { <パーミッション> };
例:
dontaudit traceroute_t { port_type -port_t }:tcp_socket name_bind;
<br>
==== neverallowルール ====
allowルールが操作に対して生成されてはならないことを指定する。<br>
これは以前に許可されていた場合でも同様である。<br>
<br>
neverallow文は、コンパイラで強制されるアクションであり、checkpolicyまたはcheckmoduleコンパイラは、ポリシーソース内にallowルールが生成されているかを確認して、生成されている場合は警告を発して停止する。<br>
<br>
neverallow <ソースタイプ> <ターゲットタイプ>:<クラス> { <パーミッション> };
例:
neverallow ~can_read_shadow_passwords shadow_t:file read;
neverallow { domain -mmap_low_domain_type } self:memprotect mmap_zero;
<br>
<u>※注意</u><br>
<u>neverallowステートメントはモジュール内で許可されているが、これらを検出するにはsemanage.confファイルにexpand-check=1エントリが存在する必要がある。</u><br>
<br>
==== require文 ====
モジュールポリシーソースファイル内で、外部ソースファイルから必要なポリシーコンポーネントを示すために使用される。<br>
<br>
require {
    <要求リスト>
};
例:
require {
    role system_r;
    type httpd_t, httpd_exec_t;
    class file { read write };
};
<br>
<center>
{| class="wikitable"
|+ 有効なrequire文キーワード
! キーワード !! 書式 !! 説明 !! 例
|-
| rowspan="7" | 識別子リスト型
| role || カンマ区切りの識別子リスト<br>最後はセミコロンで終わる。 || require { role system_r, user_r; };
|-
| type || カンマ区切りの識別子リスト<br>最後はセミコロンで終わる。 || require { type httpd_t, httpd_exec_t; };
|-
| attribute || カンマ区切りの識別子リスト<br>最後はセミコロンで終わる。 || require { attribute domain, daemon; };
|-
| user || カンマ区切りの識別子リスト<br>最後はセミコロンで終わる。 || require { user user_u, staff_u; };
|-
| bool || カンマ区切りの識別子リスト<br>最後はセミコロンで終わる。 || require { bool httpd_enable_cgi; };
|-
| sensitivity || カンマ区切りの識別子リスト<br>最後はセミコロンで終わる。 || require { sensitivity s0, s1; };
|-
| category || カンマ区切りの識別子リスト<br>最後はセミコロンで終わる。 || require { category c0, c1; };
|-
| class || 単一のクラス識別子 + パーミッションリスト || クラスキーワードの後に、単一のオブジェクトクラス識別子が続き、<br>その後に1つ以上のパーミッションが続く。<br>複数のパーミッションは中括弧で囲まれたスペース区切りのリスト || require { class file { read write }; };
|}
</center>
<br>
複数のキーワードを同一のrequireブロック内で使用することができる。<br>
<br>
require {
    role system_r;
    type httpd_t, httpd_exec_t;
    class file { read write getattr };
    class dir { search };
};
<br>
<u>※注意</u><br>
<u>requireステートメントキーワードのみが、require {...} ブロック内で許可される。</u><br>
<br>
==== gen_requireマクロ ====
Reference Policyマクロとして、モジュールファイル内でrequireブロックを挿入するために使用される。<br>
<br>
gen_require(`
    <要求ステートメント>
')
例:
gen_require(`
    type ftpd_etc_t;
')
<br>
<br>
==== インタフェース使用 ====
==== インタフェース使用 ====
328行目: 514行目:
これにより、ポリシーの記述が簡潔になり、一貫性が保たれる。<br>
これにより、ポリシーの記述が簡潔になり、一貫性が保たれる。<br>
<br>
<br>
  インタフェース名(<タイプ1>, <タイプ2>, ...)
  インタフェース名(<引数1>, <引数2>, ...)
   
   
  例:
  例:
  files_read_etc_files(myapp_t)
  files_read_etc_files(myapp_t)
logging_log_file(myapp_log_t)
domain_type(myapp_t)
domain_entry_file(myapp_t, myapp_exec_t)
<br>
<br>
==== 属性の定義と割り当て ====
<center>
複数のタイプをグループ化する。<br>
{| class="wikitable"
|+ 一般的に使用されるインタフェースの例
! インタフェース名 !! カテゴリ !! 説明 !! 引数 !! 使用例
|-
| files_read_etc_files() || ファイルアクセス || /etcディレクトリ内のファイルの読み取りを許可 || ドメインタイプ || files_read_etc_files(myapp_t)
|-
| files_type() || タイプ宣言 || ファイルシステムタイプとして宣言する。<br>ファイルシステム関連の共通属性を自動的に割り当てる。 || タイプ識別子 || files_type(myapp_data_t)
|-
| logging_log_file() || タイプ宣言 || ログファイルタイプとして宣言する。<br>ログディレクトリへのアクセス権限を設定 || タイプ識別子 || logging_log_file(myapp_log_t)
|-
| domain_type() || タイプ宣言 || ドメインタイプとして宣言する。<br>プロセスドメインとしての属性を付与する。 || タイプ識別子 || domain_type(myapp_t)
|-
| domain_entry_file() || ドメイン遷移 || ドメインエントリポイントとして宣言する。<br>指定した実行ファイルからドメインへの遷移を設定 || ドメインタイプ、実行ファイルタイプ || domain_entry_file(myapp_t, myapp_exec_t)
|-
| corecmd_exec_bin() || コマンド実行 || /bin、/usr/bin内のコマンドの実行を許可 || ドメインタイプ || corecmd_exec_bin(myapp_t)
|-
| files_search_etc() || ファイルアクセス || /etcディレクトリの検索を許可 || ドメインタイプ || files_search_etc(myapp_t)
|-
| files_read_usr_files() || ファイルアクセス || /usrディレクトリ内のファイルの読み取りを許可 || ドメインタイプ || files_read_usr_files(myapp_t)
|-
| kernel_read_system_state() || システムアクセス || カーネルシステム状態の読み取りを許可 || ドメインタイプ || kernel_read_system_state(myapp_t)
|-
| corenet_tcp_bind_generic_node() || ネットワーク || 任意のネットワークノードへのTCPバインドを許可 || ドメインタイプ || corenet_tcp_bind_generic_node(myapp_t)
|-
| logging_search_logs() || ファイルアクセス || ログディレクトリの検索を許可 || ドメインタイプ || logging_search_logs(myapp_t)
|-
| init_daemon_domain() || タイプ宣言 || initデーモンドメインとして宣言する。<br>systemdから起動されるサービス用 || ドメインタイプ、実行ファイルタイプ || init_daemon_domain(myservice_t, myservice_exec_t)
|}
</center>
<br>
<br>
* 属性名
<u>※注意</u><br>
*: 複数のタイプをグループ化するために使用される。
<u>これらはReference Policyマクロであり、.ifファイル内で定義されたインタフェースである。</u><br>
*: これにより、複数のタイプに対して1度にルールを適用できる。
<u>使用時には、各インタフェースのドキュメントを参照して、必要な引数と動作を確認すること。</u><br>
*: 例えば、全てのネットワークデーモンに共通のルールを適用する場合等に便利である。
<br>
attribute <属性名>;
typeattribute <タイプ名> <属性名>;
例:
attribute myapp_domain;
typeattribute myapp_t myapp_domain;
<br>
<br>
==== ブール値の定義 ====
==== ブール値の定義 ====
352行目: 561行目:
ブール値は、ランタイムでポリシーの動作を変更するために使用される。<br>
ブール値は、ランタイムでポリシーの動作を変更するために使用される。<br>
<br>
<br>
管理者は、<code>setsebool</code>コマンドを使用してこれらの値を変更できる。<br>
管理者は、setseboolコマンドを使用してこれらの値を変更できる。<br>
これにより、システムの再起動やポリシーの再コンパイル無しでポリシーを調整できる。<br>
これにより、システムの再起動やポリシーの再コンパイル無しでポリシーを調整できる。<br>
<br>
<br>
  bool <ブール名> default <初期値>;
  bool <ブール名> <デフォルト値>;
   
   
  例:
  例:
  bool myapp_enable_feature default false;
  bool myapp_enable_feature false;
bool allow_execheap false;
bool allow_execstack true;
<br>
デフォルト値は、true または false である。<br>
<br>
<br>
==== 条件付きポリシー ====
==== 条件付きポリシー ====
366行目: 579行目:
これにより、単一のポリシーモジュール内で異なる設定をサポートすることができる。<br>
これにより、単一のポリシーモジュール内で異なる設定をサポートすることができる。<br>
<br>
<br>
  if (<条件>) {
  if (<条件式>) {
     // ポリシールール
     <trueリスト>
}
if (<条件式>) {
    <trueリスト>
  }
  }
  else {
  else {
     // 別のポリシールール
     <falseリスト>
  }
  }
   
   
376行目: 593行目:
  if (myapp_enable_feature) {
  if (myapp_enable_feature) {
     allow myapp_t user_home_t:file { read write };
     allow myapp_t user_home_t:file { read write };
}
if (allow_daemons_use_tty) {
    term_use_all_terms(daemon)
}
else {
    term_dontaudit_use_all_terms(daemon)
  }
  }
<br>
条件式で使用可能な論理演算子:<br>
* &&  (論理AND)
* ||  (論理OR)
* ^  (排他的OR、XOR)
* !  (論理NOT)
* ==  (等しい)
* !=  (等しくない)
<br>
if/else構成内で許可されるステートメントとルール:<br>
* allow、auditallow、dontaudit
* type_member、type_change
* type_transition (ファイル名遷移を除く)
* require
<br>
<u>※注意</u><br>
<u>neverallowとauditdeny (非推奨) は条件付きステートメント内では許可されない。</u><br>
<br>
==== optional文 ====
ポリシーステートメントが最終的にコンパイルされたポリシーに存在する場合と存在しない場合を示すために使用される。<br>
<br>
optional {...} 内の全てのステートメントが正常に展開できる場合にのみ、ステートメントがポリシーに含まれる。<br>
これは通常、リストの先頭でrequireステートメントを使用することで実現される。<br>
<br>
optional {
    <ルールリスト>
}
optional {
    <ルールリスト>
} else {
    <代替ルールリスト>
}
例:
optional_policy(`
    unconfined_domain(ada_t)
')
<br>
<br>
==== ロールの割り当て ====
==== ロールの割り当て ====
384行目: 646行目:
*: ユーザがアクセスできるドメイン (タイプ) を制限するために使用される。
*: ユーザがアクセスできるドメイン (タイプ) を制限するために使用される。
*: 特定のロールにタイプを関連付けることにより、そのロールを持つユーザのみがそのタイプのプロセスを実行できる。
*: 特定のロールにタイプを関連付けることにより、そのロールを持つユーザのみがそのタイプのプロセスを実行できる。
*: ロール識別子は、慣例として _r で終わる。(強制ではない)
<br>
<br>
  role <ロール名> types <タイプ名>;
  role <ロール名> types <タイプ名>;
389行目: 652行目:
  例:
  例:
  role system_r types myapp_t;
  role system_r types myapp_t;
role user_r types user_t;
<br>
===== role allowルール =====
ロールの変更が許可されているかどうかを確認する。<br>
許可されている場合、role_transitionのさらなる要求が行われ、プロセスが新しいロールまたはロールセットで実行される。<br>
<br>
allow <ソースロール名> <ターゲットロール名>;
例:
allow sysadm_r secadm_r;
<br>
===== role_transitionルール =====
ロール遷移が必要であることを指定する。<br>
許可されている場合、プロセスは新しいロールで実行される。<br>
<br>
ポリシーバージョン25以降、クラスを定義できる。<br>
<br>
role_transition <ソースロール> <ターゲットタイプ> <クラス> <デフォルトロール>;
例:
role_transition system_r httpd_exec_t:process system_r;
<br>
<br>
==== ファイルコンテキストの指定 ====
==== ファイルコンテキストの指定 ====
401行目: 685行目:
  例:
  例:
  files_type(myapp_data_t)
  files_type(myapp_data_t)
files_type(myapp_log_t)
<br>
<u>※注意</u><br>
<u>files_type()は、Reference Policyマクロであり、ポリシー言語の標準ステートメントではない。</u><br>
<br>
==== 予約語 ====
下表のキーワードは、SELinuxポリシー言語で予約されている。<br>
<br>
<center>
{| class="wikitable"
! colspan="4" | 予約語リスト
|-
| alias || allow || and || attribute
|-
| attribute_role || auditallow || auditdeny || bool
|-
| category || cfalse || class || clone
|-
| common || constrain || ctrue || dom
|-
| domby || dominance || dontaudit || else
|-
| equals || false || filename || filesystem
|-
| fscon || fs_use_task || fs_use_trans || fs_use_xattr
|-
| genfscon || h1 || h2 || identifier
|-
| if || incomp || inherits || iomemcon
|-
| ioportcon || ipv4_addr || ipv6_addr || l1
|-
| l2 || level || mlsconstrain || mlsvalidatetrans
|-
| module || netifcon || neverallow || nodecon
|-
| not || notequal || number || object_r
|-
| optional || or || path || pcidevicecon
|-
| permissive || pirqcon || policycap || portcon
|-
| r1 || r2 || r3 || range
|-
| range_transition || require || role || roleattribute
|-
| roles || role_transition || sameuser || sensitivity
|-
| sid || source || t1 || t2
|-
| t3 || target || true || type
|-
| typealias || typeattribute || typebounds || type_change
|-
| type_member || types || type_transition || u1
|-
| u2 || u3 || user || validatetrans
|-
| version_identifier || xor || default_user || default_role
|-
| default_type || default_range || low || high
|-
| low_high || || ||
|}
</center>
<br>
==== ポリシーファイルタイプ別の有効なステートメント ====
下表に、各タイプのポリシーソースファイルで許可されるステートメントとルールを示す。<br>
<br>
<center>
{| class="wikitable"
! ステートメント/ルール !! モノリシックポリシー !! ベースポリシー !! モジュールポリシー !! 条件付きステートメント !! optional文 !! require文
|-
| allow || 可 || 可 || 可 || 可 || 可 || 不可
|-
| allow - Role || 可 || 可 || 可 || 不可 || 可 || 不可
|-
| attribute || 可 || 可 || 可 || 不可 || 可 || 可
|-
| auditallow || 可 || 可 || 可 || 可 || 可 || 不可
|-
| bool || 可 || 可 || 可 || 不可 || 可 || 可
|-
| dontaudit || 可 || 可 || 可 || 可 || 可 || 不可
|-
| if || 可 || 可 || 可 || 不可 || 可 || 不可
|-
| neverallow || 可 || 可 || 可 || 不可 || 可 || 不可
|-
| optional || 不可 || 可 || 可 || 可 || 可 || 可
|-
| require || 不可 || 可 || 可 || 可 || 可 || 不可
|-
| role || 可 || 可 || 可 || 不可 || 可 || 可
|-
| role_transition || 可 || 可 || 可 || 不可 || 可 || 不可
|-
| type || 可 || 可 || 可 || 不可 || 不可 || 可
|-
| type_change || 可 || 可 || 可 || 可 || 可 || 不可
|-
| type_member || 可 || 可 || 可 || 可 || 可 || 不可
|-
| type_transition || 可 || 可 || 可 || 可 (注1) || 可 || 不可
|-
| typeattribute || 可 || 可 || 可 || 不可 || 可 || 不可
|-
| user || 可 || 可 || 可 || 不可 || 可 || 可
|}
</center>
<br>
<u>※注意</u><br>
<u>ファイル名遷移ルールを除く。</u><br>
<br>
==== 一般的なルール ====
===== 識別子の命名規則 =====
* 識別子は一般的に任意の長さにできるが、以下の文字に制限する必要がある。
*: a-z、A-Z、0-9、_ (アンダースコア)
* 慣例により、タイプ識別子は _t で終わる。
* 慣例により、ロール識別子は _r で終わる。
* 慣例により、ユーザ識別子は _u で終わる。
* 属性識別子は、タイプと区別するために _t 以外で終わる。
<br>
===== コメント =====
* # はポリシーソースファイルでのコメントの開始を示す。
<br>
===== マクロとスペース =====
* マクロ名とそのパラメータの間にスペースは許可されない。
* 正しい例
*: policy_module(ftp, 1.7.0)
* 誤った例
*: policy_module (ftp, 1.7.0)
<br>
===== 複数エントリの展開 =====
単一のステートメントまたはルールに複数のソースとターゲットエントリが表示される場合、コンパイラ (checkpolicy または checkmodule) はこれらを個別のステートメントまたはルールに展開する。<br>
<br>
例:
allow apm_t { console_device_t tty_device_t }:chr_file { getattr read write };
# コンパイラは以下のように展開する:
allow apm_t console_device_t:chr_file { getattr read write };
allow apm_t tty_device_t:chr_file { getattr read write };
<br><br>
<br><br>


{{#seo:
|title={{PAGENAME}} : Exploring Electronics and SUSE Linux | MochiuWiki
|keywords=MochiuWiki,Mochiu,Wiki,Mochiu Wiki,Electric Circuit,Electric,pcb,Mathematics,AVR,TI,STMicro,AVR,ATmega,MSP430,STM,Arduino,Xilinx,FPGA,Verilog,HDL,PinePhone,Pine Phone,Raspberry,Raspberry Pi,C,C++,C#,Qt,Qml,MFC,Shell,Bash,Zsh,Fish,SUSE,SLE,Suse Enterprise,Suse Linux,openSUSE,open SUSE,Leap,Linux,uCLnux,電気回路,電子回路,基板,プリント基板
|description={{PAGENAME}} - 電子回路とSUSE Linuxに関する情報 | This page is {{PAGENAME}} in our wiki about electronic circuits and SUSE Linux
|image=/resources/assets/MochiuLogo_Single_Blue.png
}}


__FORCETOC__
__FORCETOC__
[[カテゴリ:RHEL]][[カテゴリ:SUSE]][[カテゴリ:Raspberry_Pi]][[カテゴリ:PinePhone]]
[[カテゴリ:RHEL]][[カテゴリ:SUSE]][[カテゴリ:Raspberry_Pi]][[カテゴリ:PinePhone]]
「http://mochiuwiki.e2.valueserver.jp/index.php?title=設定_-_SELinux」から取得