SELinux 的安全模型把所有访问控制规则描述为主体实体（通常是数据库的客户端）与客体实体（例如数据库对象）之间的关系，每一方都由安全标签标识。如果尝试访问一个未打标签的对象，该对象会被视为被分配了 unlabeled_t 标签。

目前，sepgsql 允许把安全标签分配给模式、表、列、序列、视图与函数。使用 sepgsql 时，支持类型的数据库对象在创建时会被自动分配安全标签。该标签称为默认安全标签，它依据系统安全策略决定，系统安全策略把创建者的标签、分配给新对象父对象的标签，以及可选的被构造对象的名称作为输入。

新的数据库对象基本上继承父对象的安全标签，除非安全策略有被称为类型转换规则的特殊规则，此时可能应用不同的标签。对模式而言，父对象是当前数据库；对表、序列、视图与函数而言，父对象是所在模式；对列而言，父对象是所在的表。

对表而言，会根据语句的种类为所有被引用的目标表检查 db_table:select、db_table:insert、db_table:update 或 db_table:delete；此外，对包含 WHERE 或 RETURNING 子句中引用的列、作为 UPDATE 数据来源等的所有表，也会检查 db_table:select。

每个被引用的列也会检查列级权限。不仅使用 SELECT 读取的列会检查 db_column:select，其他 DML 语句中引用的列也会检查；被 UPDATE 或 INSERT 修改的列还会检查 db_column:update 或 db_column:insert。

例如，考虑：

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

这里，t1.x 被更新，因此会检查 db_column:update；t1.y 既被更新又被引用，因此会检查 db_column:{select update}；t1.z 只被引用，因此会检查 db_column:select。在表级还会检查 db_table:{select update}。

对序列而言，当我们用 SELECT 引用序列对象时会检查 db_sequence:get_value；不过请注意，我们目前不检查执行 lastval() 等相应函数的权限。

对视图而言，会检查 db_view:expand，然后对从视图展开出来的对象逐个检查任何其他所需的权限。

对函数而言，当用户尝试在查询中执行函数或通过快速路径调用时，会检查 db_procedure:{execute}。如果该函数是可信过程，还会检查 db_procedure:{entrypoint} 权限，确认它可以作为可信过程的入口点。

要访问任何模式对象，需要在包含它的模式上具备 db_schema:search 权限。当对象被不带模式限定地引用时，不具备该权限的模式不会被搜索（就像用户对模式没有 USAGE 特权一样）。如果存在显式的模式限定，而用户对被命名模式不具备所需的权限，则会发生错误。

客户端必须被允许访问所有被引用的表与列，即使它们来自随后被展开的视图，这样我们才能以与引用表内容的方式无关的一致访问控制规则行事。

默认的数据库特权系统允许数据库超级用户用 DML 命令修改系统目录，并引用或修改 toast 表。sepgsql 启用时这些操作被禁止。

SELinux 为每种对象类型定义了若干权限来控制常见操作，例如创建、修改、删除与安全标签的重新打标。此外，若干对象类型还有控制其特有操作的专用权限，例如在特定模式内添加或删除名称条目。

创建新的数据库对象需要 create 权限。SELinux 会基于客户端的安全标签与新对象建议的安全标签授予或拒绝该权限。在某些情况下，还需要额外的特权：

执行 DROP 命令时，会对被移除的对象检查 drop。通过 CASCADE 间接删除的对象也会检查权限。删除特定模式内的对象（表、视图、序列与过程）另外需要对模式本身的 remove_name 权限。

执行 ALTER 命令时，对每种对象类型都会在被修改的对象上检查 setattr；对表的索引或触发器这类附属对象例外，此时权限改为在父对象上检查。在某些情况下，还需要额外的权限：

可信过程类似于安全定义者函数或 setuid 命令。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

以上操作应当由管理用户执行。

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)

在此例中，普通用户无法直接引用 customer.credit，但可信过程 show_credit 允许用户打印客户的信用卡号，其中部分数字被遮蔽。

如果安全策略允许，可以使用 SELinux 的动态域转换特性把客户端进程（即客户端域）的安全标签切换到新的上下文。客户端域需要 setcurrent 权限，以及从旧域到新域的 dyntransition 权限。

动态域转换应被慎重对待，因为它允许用户按自己的意愿切换自己的标签、进而切换自己的特权，而非（像可信过程那样）由系统强制规定。因此，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

在上面的示例中，我们被允许从较大的 MCS 范围 c1.c1023 切换到较小的范围 c1.c4，但切回被拒绝了。

动态域转换与可信过程的组合能够支持一种契合连接池软件典型进程生命周期的有趣用例。即使你的连接池软件不被允许运行大多数 SQL 命令，你也可以允许它通过 sepgsql_setcon() 函数在可信过程内部切换客户端的安全标签；这应当需要某种凭证来授权切换客户端标签的请求。此后，该会话将拥有目标用户的特权，而非连接池的特权。连接池随后可以再次使用带 NULL 参数的 sepgsql_setcon() 恢复安全标签的更改，同样是在具有适当权限检查的可信过程内部调用。关键在于：只有可信过程真正拥有更改生效安全标签的权限，并且只有在提供正确凭证时才会这么做。当然，为了安全运作，凭证存储（表、过程定义或其他形式）必须防止未授权访问。

我们一律拒绝 LOAD 命令，因为任何被加载的模块都可能轻易绕过安全策略的执行。