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

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

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

对于表，根据语句的类型，会检查所有引用的目标表是否具有 db_table:select、db_table:insert、db_table:update 或 db_table:delete 权限；此外，还会检查所有包含 WHERE 或 RETURNING 子句中引用的列的表是否具有 db_table:select 权限，作为 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 命令，因为任何加载的模块都可能轻松绕过安全策略执行。