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

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

新的資料庫物件基本上會繼承父物件的安全標籤，除非安全政策有特殊規則（稱為類型轉換規則），在這種情況下，可能會套用不同的標籤。對於綱要，父物件是當前資料庫；對於表格、序列、檢視表和函式，它是包含的綱要；對於欄位，它是包含的表格。

對於表格，會根據陳述式的類型檢查所有參照目標表格的 db_table:select、db_table:insert、db_table:update 或 db_table:delete；此外，對於包含 WHERE 或 RETURNING 子句中參照的欄位的，以及作為 UPDATE 的資料來源的所有表格，也會檢查 db_table:select，等等。

還會針對每個參照的欄位檢查欄位層級的權限。不僅會對使用 SELECT 讀取的欄位檢查 db_column:select，還會對在其他 DML 陳述式中參照的欄位檢查；還會對使用 UPDATE 或 INSERT 修改的欄位檢查 db_column:update 或 db_column: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 指令，因為任何載入的模組都可能輕易規避安全策略的強制執行。