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

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

新的数据库对象基本上继承父对象的安全标签，除非安全策略具有称为类型转换规则的特殊规则，在这种情况下可能会应用不同的标签。对于模式，父对象是当前数据库；对于表、序列、视图和函数，它是包含它们的模式；对于列，它是包含它们的表。

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

还会检查每个引用列的列级权限。db_column:select 不仅在用 SELECT 读取的列上进行检查，还在其他 DML 语句中引用的列上进行检查；db_column:update 或 db_column:insert 也会在用 UPDATE 或 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() 函数切换客户端的安全标签；这应该需要一些凭据来授权切换客户端标签的请求。之后，此会话将拥有目标用户的权限，而不是连接池程序的权限。连接池程序稍后可以通过再次使用 sepgsql_setcon() 和 NULL 参数来恢复安全标签的更改，再次从具有适当权限检查的受信任过程中调用。这里的重点是，只有受信任的过程实际上具有更改有效安全标签的权限，并且仅在获得适当的凭据时才这样做。当然，为了安全运行，凭据存储（表、过程定义或其他任何内容）必须受到保护，防止未经授权的访问。

我们全面拒绝 LOAD 命令，因为加载的任何模块都可能轻易规避安全策略的执行。