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 命令，因为加载的任何模块都可以轻松规避安全策略实施。