The security model of <productname>SELinux</productname> describes all the access control rules as relationships between a subject entity (typically, a client of the database) and an object entity (such as a database object), each of which is identified by a security label. If access to an unlabeled object is attempted, the object is treated as if it were assigned the label <literal>unlabeled_t</literal>. SELinuxのセキュリティモデルでは、全てのアクセス制御ルールは動作主体（サブジェクト; 典型的にはデータベースクライアント）と対象オブジェクト間の関係として記述し、これらはセキュリティラベルによって識別されます。 ラベル付けされていないオブジェクトに対するアクセスが発生した場合、そのオブジェクトはあたかもunlabeled_tタイプが割り当てられているかのように振舞います。

Currently, <filename>sepgsql</filename> allows security labels to be assigned to schemas, tables, columns, sequences, views, and functions. When <filename>sepgsql</filename> is in use, security labels are automatically assigned to supported database objects at creation time. This label is called a default security label, and is decided according to the system security policy, which takes as input the creator's label, the label assigned to the new object's parent object and optionally name of the constructed object. 現在のsepgsqlでは、スキーマ、テーブル、カラム、シーケンス、ビューおよび関数に対するラベル付けがサポートされています。 sepgsqlの利用時には、これらのデータベースオブジェクトに対して、その生成時に自動的にセキュリティラベルが割り当てられます。 このラベルはデフォルトセキュリティラベルと呼ばれ、作成者のラベル、親関係にあたるオブジェクトのラベル、そして場合によっては作成されたオブジェクトの名前に基づいて、システムのセキュリティポリシーが決定します。

A new database object basically inherits the security label of the parent object, except when the security policy has special rules known as type-transition rules, in which case a different label may be applied. For schemas, the parent object is the current database; for tables, sequences, views, and functions, it is the containing schema; for columns, it is the containing table. 新しいデータベースオブジェクトのラベルは、タイプ遷移と呼ばれる異なったラベルを設定するための特別なルールがセキュリティポリシーに設定されている場合を除き、親関係にあるオブジェクトのラベルを引き継ぎます。 スキーマの親オブジェクトはデータベースであり、テーブル、シーケンス、ビュー、および関数はその属するスキーマが、カラムはその属するテーブルが親オブジェクトという事になります。

For tables, <literal>db_table:select</literal>, <literal>db_table:insert</literal>, <literal>db_table:update</literal> or <literal>db_table:delete</literal> are checked for all the referenced target tables depending on the kind of statement; in addition, <literal>db_table:select</literal> is also checked for all the tables that contain columns referenced in the <literal>WHERE</literal> or <literal>RETURNING</literal> clause, as a data source for <literal>UPDATE</literal>, and so on. テーブルに対しては、構文の種類に応じてdb_table:select、db_table:insert、db_table:updateあるいはdb_table:delete権限が全ての被参照テーブルに対してチェックされます。 加えて、WHERE句やRETURNING句で参照されるカラム、又はUPDATEの際のデータ元として利用されるカラムの属するテーブルに対してdb_table:select権限もチェックされます。

Column-level permissions will also be checked for each referenced column. <literal>db_column:select</literal> is checked on not only the columns being read using <literal>SELECT</literal>, but those being referenced in other DML statements; <literal>db_column:update</literal> or <literal>db_column:insert</literal> will also be checked for columns being modified by <literal>UPDATE</literal> or <literal>INSERT</literal>. 参照された全てのカラムに対して列レベルの権限チェックが行われます。 SELECT構文で読み出されるカラムに対してだけでなく、他のDML構文で参照されているカラムに対してもdb_column:select権限がチェックされます。 また、UPDATEやINSERTによって操作の対象となっているカラムに対しても、db_column:updateやdb_column:insert権限がそれぞれチェックされます。

For example, consider: 以下の例を見てください

UPDATE t1 SET x = 2, y = func1(y) WHERE z = 100;

Here, <literal>db_column:update</literal> will be checked for <literal>t1.x</literal>, since it is being updated, <literal>db_column:{select update}</literal> will be checked for <literal>t1.y</literal>, since it is both updated and referenced, and <literal>db_column:select</literal> will be checked for <literal>t1.z</literal>, since it is only referenced. <literal>db_table:{select update}</literal> will also be checked at the table level. ここでは、更新されるt1.xに対してdb_column:update権限が、更新と同時に参照されるt1.yに対してはdb_column:{select update}権限が、そして参照されるだけのt1.zにはdb_column:select権限がチェックされます。 また、テーブルレベルではdb_table:{select update}権限がチェックされます。

For sequences, <literal>db_sequence:get_value</literal> is checked when we reference a sequence object using <literal>SELECT</literal>; however, note that we do not currently check permissions on execution of corresponding functions such as <literal>lastval()</literal>. SELECT構文を用いてシーケンスを参照する場合、db_sequence:get_valueがチェックされます。 しかし、現在のところlastval()など関連する関数の実行時にはパーミッションチェックを行わない事に留意してください。

For views, <literal>db_view:expand</literal> will be checked, then any other required permissions will be checked on the objects being expanded from the view, individually. ビューに対してはdb_view:expand権限がチェックされ、次いで、ビューから展開されたオブジェクトに対するパーミッションが個別にチェックされます。

For functions, <literal>db_procedure:{execute}</literal> will be checked when user tries to execute a function as a part of query, or using fast-path invocation. If this function is a trusted procedure, it also checks <literal>db_procedure:{entrypoint}</literal> permission to check whether it can perform as entry point of trusted procedure. 利用者がクエリの一部として、あるいは近道インタフェースを用いた呼び出しによって関数を実行しようとするとき、db_procedure:{execute}権限がチェックされます。 関数がトラステッドプロシージャである場合、関数がトラステッドプロシージャのエントリポイントとして振る舞う事ができるかどうかを検査するためにdb_procedure:{entrypoint}権限がチェックされます。

In order to access any schema object, <literal>db_schema:search</literal> permission is required on the containing schema. When an object is referenced without schema qualification, schemas on which this permission is not present will not be searched (just as if the user did not have <literal>USAGE</literal> privilege on the schema). If an explicit schema qualification is present, an error will occur if the user does not have the requisite permission on the named schema. あらゆるスキーマオブジェクトにアクセスするためには、それらを含むスキーマに対するdb_schema:search権限が必要です。 あるスキーマオブジェクトがスキーマ修飾無しに参照された場合、この権限を与えられていないスキーマは探索されません（あたかも利用者がスキーマに対するUSAGE権限を有していないかのように振る舞います）。 明示的なスキーマ修飾があり、このスキーマに対して利用者が要求された権限を有していない場合、エラーが発生します。

The client must be allowed to access all referenced tables and columns, even if they originated from views which were then expanded, so that we apply consistent access control rules independent of the manner in which the table contents are referenced. クライアントは全ての被参照テーブル・カラムに対して参照の権限を有している必要があります。それらがビューに由来し、展開されたものであっても同様です。これにより、テーブルの内容がどのような方法によって参照されるかに関係なく、一貫したアクセス制御ルールを適用する事ができます。

The default database privilege system allows database superusers to modify system catalogs using DML commands, and reference or modify toast tables. These operations are prohibited when <filename>sepgsql</filename> is enabled. データベーススーパーユーザに対して、デフォルトのデータベース権限システムはDMLを用いたシステムカタログの更新と、TOASTテーブルの参照および更新を許していますが、sepgsqlが有効なとき、これらの操作は禁止されます。

<productname>SELinux</productname> defines several permissions to control common operations for each object type; such as creation, alter, drop and relabel of security label. In addition, several object types have special permissions to control their characteristic operations; such as addition or deletion of name entries within a particular schema. オブジェクトの作成、変更、削除やセキュリティラベルの変更など、SELinuxは各オブジェクトに共通の操作を制御するためのパーミッションを何個か定義しています。 また、特定のスキーマに対する名前の追加や削除など、いくつかのオブジェクトにはそれ固有の操作を制御するための特別なパーミッションも定義されています。

Creating a new database object requires <literal>create</literal> permission. <productname>SELinux</productname> will grant or deny this permission based on the client's security label and the proposed security label for the new object. In some cases, additional privileges are required: 新しいデータベースオブジェクトの作成にはcreate権限が必要です。 SELinuxは利用者のセキュリティラベルと新しいオブジェクトに付与される事になるセキュリティラベルの対に基づいて、この権限を許可、あるいは拒否します。 いくつかの場合では、追加的な権限チェックが行われます。

When <literal>DROP</literal> command is executed, <literal>drop</literal> will be checked on the object being removed. Permissions will be also checked for objects dropped indirectly via <literal>CASCADE</literal>. Deletion of objects contained within a particular schema (tables, views, sequences and procedures) additionally requires <literal>remove_name</literal> on the schema. DROP構文の実行時、削除されるオブジェクトに対してdrop権限がチェックされます。 CASCADEにより間接的に削除されるオブジェクトに対してもチェックは行われます。 特定のスキーマに含まれるオブジェクト（テーブル、ビュー、シーケンスや関数）の削除に際しては、スキーマに対するremove_name権限も併せてチェックされます。

When <literal>ALTER</literal> command is executed, <literal>setattr</literal> will be checked on the object being modified for each object types, except for subsidiary objects such as the indexes or triggers of a table, where permissions are instead checked on the parent object. In some cases, additional permissions are required: ALTER構文の実行時、テーブルに対するインデックスやトリガなど別オブジェクトに従属するもの（これらは代わりに親オブジェクトに対する権限がチェックされる）を除き、setattrがチェックされます。 いくつかの場合では、追加的な権限チェックが行われます。

Trusted procedures are similar to security definer functions or setuid commands. <productname>SELinux</productname> provides a feature to allow trusted code to run using a security label different from that of the client, generally for the purpose of providing highly controlled access to sensitive data (e.g., rows might be omitted, or the precision of stored values might be reduced). Whether or not a function acts as a trusted procedure is controlled by its security label and the operating system security policy. For example: トラステッドプロシージャはSECURITY DEFINER関数やSet-UIDコマンドに似ています。 通常、機密データに対する高度にコントロールされたアクセス手段(例えば行を削除したり、保存された値の精度をさげたりします)を提供する目的で、SELinuxは利用者のものとは異なるセキュリティラベルで信頼済みのコードを実行するための機能を持っています。 関数がトラステッドプロシージャとして振舞うかどうかは、関数のセキュリティラベルおよびオペレーティングシステムのセキュリティポリシーに従って決まります。 例えば：

postgres=# CREATE TABLE customer (
               cid     int primary key,
               cname   text,
               credit  text
           );
CREATE TABLE
postgres=# SECURITY LABEL ON COLUMN customer.credit
               IS 'system_u:object_r:sepgsql_secret_table_t:s0';
SECURITY LABEL
postgres=# CREATE FUNCTION show_credit(int) RETURNS text
             AS 'SELECT regexp_replace(credit, ''-[0-9]+$'', ''-xxxx'', ''g'')
                        FROM customer WHERE cid = $1'
           LANGUAGE sql;
CREATE FUNCTION
postgres=# SECURITY LABEL ON FUNCTION show_credit(int)
               IS 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0';
SECURITY LABEL

The above operations should be performed by an administrative user. これらの操作は管理権限を持つ利用者で行ってください。

postgres=# SELECT * FROM customer;
ERROR:  SELinux: security policy violation
postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
 cid | cname  |     show_credit
-----+--------+---------------------
   1 | taro   | 1111-2222-3333-xxxx
   2 | hanako | 5555-6666-7777-xxxx
(2 rows)

In this case, a regular user cannot reference <literal>customer.credit</literal> directly, but a trusted procedure <literal>show_credit</literal> allows the user to print the credit card numbers of customers with some of the digits masked out. この場合、一般の利用者はcustomer.creditを直接参照することはできませんが、トラステッドプロシージャであるshow_creditを用いる事で、一部の桁がマスクされた顧客のクレジットカード番号をプリントする事が可能になります。

It is possible to use SELinux's dynamic domain transition feature to switch the security label of the client process, the client domain, to a new context, if that is allowed by the security policy. The client domain needs the <literal>setcurrent</literal> permission and also <literal>dyntransition</literal> from the old to the new domain. セキュリティポリシーによって許可されている場合、SELinuxの動的ドメイン遷移機能を用いて、利用者のラベルを新しいものに切り替える事ができます。 利用者のドメインはsetcurrent権限および、古いドメインから新しいドメインに遷移するためのdyntransition権限を有している必要があります。

Dynamic domain transitions should be considered carefully, because they allow users to switch their label, and therefore their privileges, at their option, rather than (as in the case of a trusted procedure) as mandated by the system. Thus, the <literal>dyntransition</literal> permission is only considered safe when used to switch to a domain with a smaller set of privileges than the original one. For example: 利用者に自身のラベル、すなわち権限を切り替える事を可能にする動的ドメイン遷移は、システムによる自動切り替え（トラステッドプロシージャの場合）に比べて慎重に取り扱う必要があります。 dyntransition権限は元々のドメインよりも小さな権限セットを持つドメインに切り替える場合にのみ安全であると考えられます。 例えば、

regression=# select sepgsql_getcon();
                    sepgsql_getcon
-------------------------------------------------------
 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
(1 row)

regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c4');
 sepgsql_setcon
----------------
 t
(1 row)

regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c1023');
ERROR:  SELinux: security policy violation

In this example above we were allowed to switch from the larger MCS range <literal>c1.c1023</literal> to the smaller range <literal>c1.c4</literal>, but switching back was denied. 上記の例では、広いMCSレンジc1.c1023から狭いMCSレンジc1.c4への遷移は許可されているものの、その逆は禁止されています。

A combination of dynamic domain transition and trusted procedure enables an interesting use case that fits the typical process life-cycle of connection pooling software. Even if your connection pooling software is not allowed to run most of SQL commands, you can allow it to switch the security label of the client using the <literal>sepgsql_setcon()</literal> function from within a trusted procedure; that should take some credential to authorize the request to switch the client label. After that, this session will have the privileges of the target user, rather than the connection pooler. The connection pooler can later revert the security label change by again using <literal>sepgsql_setcon()</literal> with <literal>NULL</literal> argument, again invoked from within a trusted procedure with appropriate permissions checks. The point here is that only the trusted procedure actually has permission to change the effective security label, and only does so when given proper credentials. Of course, for secure operation, the credential store (table, procedure definition, or whatever) must be protected from unauthorized access. 動的ドメイン遷移とトラステッドプロシージャの組み合わせは、典型的なコネクションプーラのライフサイクルに適合する興味深い利用法を提供します。 たとえコネクションプーリングソフトウェアが大半のSQLの実行を許可されていない場合でも、トラステッドプロシージャの内側からsepgsql_setcon()関数を用いて利用者のセキュリティラベルを切り替える事ができます。（トラステッドプロシージャは利用者のセキュリティラベルを切り替えるための認証情報を要求すべきです。） この後、現在のセッションはコネクションプーラの権限ではなく、対象となる利用者の権限で動作する事になります。 また、sepgsql_setcon()にNULL引数を与えて（適切な権限チェックを行う）トラステッドプロシージャから再び呼び出す事で、コネクションプーラは後でセキュリティラベルを元に戻す事ができます。 ここでのポイントは、トラステッドプロシージャだけが実際に有効なセキュリティラベルを変更する権限を持っており、正しい認証情報が与えられた場合にのみそれを実行するという事です。 言うまでもなく、安全な操作のためには、権限のないアクセスから認証情報を保持するテーブルや関数定義などを保護しなければなりません。

We reject the <link linkend="sql-load"><command>LOAD</command></link> command across the board, because any module loaded could easily circumvent security policy enforcement. ロードされたモジュールは、セキュリティポリシーの適用を容易にバイパスできるため、LOADコマンドの実行は全面的に禁止されています。