SELinux 的安全模型把全部访问控制规则描述为主体实体（通常是数据库客户端）与对象实体（例如数据库对象）之间的关系，这两者都由安全标签标识。如果尝试访问一个未带标签的对象，则会把它视为被赋予了 unlabeled_t 标签。

当前，sepgsql 允许为模式、表、列、序列、视图和函数分配安全标签。使用 sepgsql 时，安全标签会在受支持的数据库对象创建时自动分配。这个标签称为默认安全标签，其取值由系统安全策略决定；策略的输入包括创建者的标签、新对象父对象的标签，以及待创建对象的名称（如果需要）。

新数据库对象基本上会继承父对象的安全标签，但如果安全策略中存在称为类型转换规则的特殊规则，则可能会应用不同的标签。对于模式，父对象是当前数据库；对于表、序列、视图和函数，父对象是其所在模式；对于列，父对象是其所在表。

对于表，会根据语句类型，对所有被引用的目标表检查 db_table:select、db_table:insert、db_table:update 或 db_table:delete；此外，对于其列在 WHERE 或 RETURNING 子句中被引用的所有表，以及作为 UPDATE 数据源的所有表等，还会检查 db_table:select。

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

例如，考虑：

UPDATE t1 SET x = 2, y = md5sum(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 命令，因为装入任意模块都可能轻易绕过安全策略的强制执行。