SELinux 的安全模型將所有訪問控制規則描述為主體實體（通常是資料庫的客戶端）和物件實體（例如資料庫物件）之間的關係，每個實體都由一個安全標籤標識。如果嘗試訪問未標記的物件，則該物件將被視為分配了 unlabeled_t 標籤。

當前，sepgsql 允許將安全標籤分配給模式、表、列、序列、檢視和函式。當使用 sepgsql 時，支援的資料庫物件在建立時會自動分配安全標籤。此標籤稱為預設安全標籤，根據系統安全策略決定，該策略以建立者的標籤、分配給新物件父物件的標籤以及可選的物件名稱作為輸入。

一個新的資料庫物件基本上繼承了父物件（例如，對於模式，父物件是當前資料庫；對於表、序列、檢視和函式，它是包含它們的模式；對於列，它是包含它們的表）的安全標籤，除非安全策略有特殊的規則（稱為型別轉換規則），在這種情況下可能會應用不同的標籤。

對於表，會根據語句的型別檢查所有引用的目標表的 db_table:select、db_table:insert、db_table:update 或 db_table:delete；此外，對於包含在 WHERE 或 RETURNING 子句中引用的所有表，也會檢查 db_table:select，作為 UPDATE 等的 DML 資料來源。

還會對每個引用的列檢查列級別的許可權。 db_column:select 會在不僅讀取的列（使用 SELECT），還包括在其他 DML 語句中引用的列上進行檢查；db_column:update 或 db_column:insert 也會在由 UPDATE 或 INSERT 修改的列上進行檢查。

例如，考慮以下語句：

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

在此，db_column:update 將在 t1.x 上進行檢查，因為它正在被更新；db_column:{select update} 將在 t1.y 上進行檢查，因為它被更新和引用；db_column:select 將在 t1.z 上進行檢查，因為它僅被引用。 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 的動態域轉換功能將客戶端程序（客戶端域）的安全標籤切換到新的上下文。

應仔細考慮動態域轉換，因為它們允許使用者根據自己的選擇切換其標籤，從而切換其許可權，而不是（如受信任的過程那樣）由系統強制執行。因此，僅當用於切換到許可權集小於原始集的域時，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 命令，因為任何載入的模組都可能輕易規避安全策略的執行。