跳轉到內容

Grsecurity/RBAC 系統

Add links
來自 Wikibooks，開放世界中的開放書籍
Grsecurity
故障排除 RBAC 系統 特定於應用程式的設定


什麼是 RBAC 系統？

[編輯 | 編輯原始碼]

基於角色的訪問控制 (RBAC) 系統是一種限制系統訪問許可權的方法，用於授權使用者。如果您想限制對檔案、功能、資源或套接字的訪問許可權，包括對所有使用者，包括 root，您需要一個 RBAC 系統。這類似於強制訪問控制 (MAC) 模型。grsecurity 的其他功能僅在阻止試圖獲取 root 許可權的攻擊者時才有效，因此 RBAC 系統用於填補這一空白。可以為程序授予最小許可權，這反過來又迫使攻擊者重新評估其攻擊方法，因為獲得 root 帳戶的訪問許可權不再意味著他們擁有對系統的完全訪問許可權。可以明確地向需要它的程序授予訪問許可權，這樣 root 就可以像其他使用者一樣操作。雖然 grsecurity 及其 RBAC 系統並不完美，但它們極大地增加了成功入侵系統的難度。

在 grsecurity 中，RBAC 系統透過一個策略檔案進行管理，該檔案本質上是一組系統範圍的規則。當 RBAC 系統使用以下命令啟用時gradm，策略檔案將被解析並檢查安全漏洞，例如授予預設角色對某些敏感裝置和檔案（如策略檔案本身）的訪問許可權。如果發現安全漏洞，gradm將拒絕啟用 RBAC 系統，並向用戶提供需要修復的事項列表。當 RBAC 系統處於活動狀態時，策略檔案將受到保護，只有 admin 角色可以在此期間訪問它。為了便於建立安全的策略，gradm能夠學習系統的功能，並根據收集到的資料構建最小許可權策略（參見 學習模式）。

任何訪問控制系統的侷限性

[編輯 | 編輯原始碼]

為了避免對訪問控制系統（無論是 grsecurity 的 RBAC、SELinux、RSBAC、SMACK、TOMOYO、AppArmor 等）產生進一步的錯誤安全感，首先要說明任何訪問控制系統的侷限性。

當策略決策程式碼與作業系統核心並存時，訪問控制系統所能提供的保證型別存在基本架構限制。作業系統被入侵很容易導致訪問控制系統被入侵，並且利用作業系統核心漏洞來停用任何活動安全系統是慣例。

grsecurity 絕不是對這種基本限制的免疫，雖然它確實包含一些功能來幫助首先防止核心被利用，並且如果攻擊者確實設法利用某些型別的錯誤，則進一步使核心對攻擊者成為更惡劣的環境。該專案將繼續把新增類似的保護作為其主要目標之一。

具體來說，以下功能參與核心自保護和提高核心利用的難度

GRKERNSEC_MODHARDEN
GRKERNSEC_HIDESYM
GRKERNSEC_RANDSTRUCT
GRKERNSEC_KSTACKOVERFLOW
PAX_MEMORY_SANITIZE
PAX_MEMORY_UDEREF
PAX_MEMORY_STACKLEAK
PAX_MEMORY_STRUCTLEAK
PAX_CONSTIFY_PLUGIN
PAX_SIZE_OVERFLOW
PAX_KERNEXEC
PAX_RANDKSTACK
PAX_USERCOPY
PAX_REFCOUNT
PAX_RAP

grsecurity 還有一些始終處於活動狀態的功能（因此沒有配置時選項），這些功能有助於實現上述目標。這些包括 amd64 上的只讀和不可執行的 vsyscall 頁面（及其影子頁面）、BPF 直譯器緩衝區的加固以及更多。

雖然這些功能在阻止之前漏洞被利用方面取得了成功（並且肯定會繼續這樣做），但仍然存在許多漏洞它無法阻止被利用，並且存在整個漏洞類別（例如缺少功能檢查、某些競態條件等）它可能永遠無法阻止被利用。

正是由於任何訪問控制系統的這種基本限制，grsecurity 的 RBAC 系統才以其設計的方式進行設計：儘可能自動化、提供足夠的訪問控制級別、具有易於編輯的人類可讀配置，以及強制執行安全基本策略以消除一些管理員錯誤。

grsecurity 的 RBAC 系統或任何其他訪問控制系統都不應用於將同一臺機器上的機密資訊與非機密資訊分離。物理氣隙沒有虛擬替代品。

策略結構

[編輯 | 編輯原始碼]

策略由角色、主體和物件組成。角色是包含 Linux 發行版中存在的傳統使用者和組以及特定於 grsecurity 的特殊角色的抽象。主體是程序或目錄，物件是檔案、功能、資源、PaX 標誌和 IP ACL。主策略檔案的位置是/etc/grsec/policy。

策略結構概述

[編輯 | 編輯原始碼]

要檢視一個簡單的策略示例，請檢視與gradm一起安裝的預設/etc/grsec/policy檔案。簡而言之，RBAC 策略具有以下結構

 role <role1> <rolemode>
 <role attributes>
 subject / <subject mode>
 <subject attributes>
     / <object mode>
     <extra objects>
     <capability rules>
     <IP ACLs>
     <resource restrictions>
 subject <extra subject> <subject mode>
 <subject attributes>
     / <object mode>
     <extra objects>
    ...
 role <role2> <rolemode>
...

以預設策略為例

 role admin sA
 subject / rvka
        / rwcdmlxi

 role default G
 role_transitions admin
 subject /
        /               r
        /opt            rx
        /home           rwxcd
        /mnt            rw
        /dev
        /dev/grsec      h
...

策略規則

[編輯 | 編輯原始碼]

策略泛化

[編輯 | 編輯原始碼]

RBAC 系統中存在一些功能來幫助簡化和泛化策略。其中之一是最近新增的“replace”規則。replace 規則允許您將字串分配給變數，然後在任何主體或物件路徑名中使用該變數，使其被替換為該字串。replace 規則的語法如下

 replace <variable name> <replace string>

例如

 replace CVSROOT /home/cvs

定義的變數可以按如下方式使用

 replace CVSROOT /home/cvs
 replace PUBHTML public_html

 subject $(CVSROOT)/bin/test o
       $(CVSROOT)/grsecurity r
       /home/spender/$(PUBHTML) r
      ...

使用 replace 規則定義的變數可以在策略中的任何位置重新分配。策略中所有規則，直到變數的另一個重新定義，都將為變數使用該新分配的值。例如

 replace CVSROOT /home/cvs
 $(CVSROOT)/grsecurity r
 replace CVSROOT /var/cvs
 $(CVSROOT)/test r

會導致建立以下物件規則

 /home/cvs/grsecurity r
 /var/cvs/test r

特殊情況

[編輯 | 編輯原始碼]

在為 RBAC 系統編寫策略時，您應該瞭解一些特殊情況。

存在一些對檔案系統物件的獨特訪問，這些訪問需要特定的物件模式。例如，連線到 Unix 域套接字（例如/dev/log）的程序將需要為該套接字設定“rw”作為物件模式。

向路徑新增 setgid 或 setuid 標誌需要“m”物件模式。

建立硬連結至少需要“cl”物件模式。目標和源上的剩餘物件標誌必須匹配。例如，如果一個程序正在從 /bin/bash 建立一個硬連結到 /bin/bash2，示例規則將是

 /bin/bash rx
 /bin/bash2 rxcl

建立符號連結需要“wc”物件模式。

萬用字元物件

[編輯 | 編輯原始碼]

RBAC 系統的一個非常有用的功能是支援物件中的萬用字元。"*" 字元匹配零個或多個字元，"?" 匹配正好一個字元，而 "[]" 可用於指定要匹配的字元的包含或排除列表或範圍。根據這些萬用字元字元的使用方式，它們具有不同的效果。以下是萬用字元使用情況的四個示例

/dev/tty*      rw
/home/*/bin    rwx
/dev/tty[0-9]  rw
/dev/tty?      rw

第一個示例將匹配 /dev/ttya、/dev/tty0、/dev/ttyS0 等。由於路徑末尾的 '*' 也可以匹配 '/' 字元，如果存在 '/dev/tty/somefile' 路徑，則第一個示例也會匹配它。

第二個示例將匹配 /home/user1/bin、/home/user2/bin 等。請注意，此規則不會匹配路徑 /home/user1/test/bin，因為萬用字元字元不會匹配 '/'，除非它出現在路徑的末尾。要使用此示例的特定萬用字元物件，必須存在 /home 物件作為萬用字元物件的“錨”。如果你忘記新增一個，gradm 會提醒你。

第三個示例將匹配 /dev/tty0、/dev/tty1、...、/dev/tty9，而不會匹配其他任何內容。

第四個示例將像第一個示例一樣匹配 /dev/ttya 和 /dev/tty0，但不會匹配 /dev/ttyS0，因為只有一個字元可以匹配 '?' 萬用字元。

萬用字元在執行時進行評估，提供了一種強大的方式來指定和簡化策略。由於萬用字元匹配基於路徑名而不是 inode/裝置對，因此它們不打算用於在策略啟用時已知是硬連結的物件。

角色

[編輯 | 編輯原始碼]

角色本質上是作為一組主題的容器，用於特定場景。存在使用者角色、組角色、預設角色和特殊角色。請參閱 匹配流程，以瞭解如何將角色與特定程序匹配。

使用者角色

[編輯 | 編輯原始碼]

簡而言之，使用者角色是在程序由特定 UID 的使用者執行或程序更改為特定 UID 時自動應用的角色。在 RBAC 系統中，使用者角色的名稱必須與系統上實際使用者的名稱匹配。

使用者角色看起來像

role user1 u

組角色

[編輯 | 編輯原始碼]

與使用者角色一樣，組角色與特定 GID 相關。組角色的名稱必須與系統上實際組的名稱匹配。請注意，這僅與程序的 GID 相關，而不與程序可能具有的任何補充組相關。如果使用者角色不匹配程序的 UID，則僅對給定程序應用組角色。

組角色看起來像

role group1 g

預設角色

[編輯 | 編輯原始碼]

如果使用者角色和組角色都不匹配給定程序，則會為它分配預設角色。預設角色理想情況下應該是一個幾乎沒有系統訪問許可權的角色。如果使用完全系統學習，則以這種方式配置它。

預設角色看起來像

role default

特殊角色

[編輯 | 編輯原始碼]

特殊角色用於向普通使用者帳戶授予額外許可權。特殊角色的一些示例用途是提供可以重啟服務和編輯系統配置檔案的“管理員”角色。也可以為普通使用者提供特殊角色，以提高其帳戶的安全性。如果他們有自己的 public_html 目錄，則該使用者的使用者角色可以使此目錄只讀，而允許使用者轉換到的特殊角色可以允許修改目錄中的檔案。

特殊角色有兩種形式，一種需要身份驗證，另一種不需要。在需要身份驗證的特殊角色方面，RBAC 系統支援一個標誌，允許將 PAM 身份驗證用於特殊角色。請參閱 角色模式，以瞭解所有這些標誌的列表。

除非存在可以向它們轉換的非特殊（使用者、組或預設）角色，否則特殊角色本身不會執行任何操作。這種轉換由 role_transitions 規則定義，在 角色屬性 頁面中進行了描述。

要對特殊角色進行身份驗證，請使用gradm -a <rolename>。要使用 PAM 對特殊角色進行身份驗證，請使用gradm -p <rolename>。要轉換到不需要身份驗證的特殊角色，請使用gradm -n <rolename>.

特殊角色看起來像

role specialauth s

role specialnoauth sN

role specialpamauth sP

域

[編輯 | 編輯原始碼]

使用域，你可以將不共享共同組 ID 的使用者以及組組合在一起，以便它們共享單個策略。域的工作方式與角色相同，唯一的例外是使用以下內容之一替換以“角色”開頭的行

domain somedomainname u user1 user2 user3 user4... usern
domain somedomainname g group1 group2 group3 group4... groupn

示例

domain somedomain u daemon bin www-data
subject /
    /    h

與使用者和組角色一樣，所有域成員都必須存在，如果它們不存在，則會引發錯誤。

主題

[編輯 | 編輯原始碼]

主題可以描述目錄、二進位制檔案或指令碼。目前不允許對主題使用正則表示式。將主題放在指令碼上的能力是獨一無二的，因為它允許你向特定指令碼授予許可權，而不是一般地向關聯的指令碼直譯器授予許可權。為了使此功能正常執行，請確保指令碼的直譯器指令不使用 #!/usr/bin/env，而是使用直譯器的完整路徑。

功能限制

[編輯 | 編輯原始碼]

當對給定主題不使用任何功能限制規則時，系統通常授予該主題內程序的所有功能都可以使用。如果涉及的主題使用策略繼承，則這是一個例外。在這種情況下，功能限制將來自正在繼承的主題。功能規則具有 +CAP_NAME 或 -CAP_NAME 的形式。CAP_ALL 是一個偽功能，用於描述整個功能列表。它主要用於刪除主題的所有功能使用，或與授予使用單個功能能力的少量規則一起使用。以下是功能限制使用情況的一些示例場景，以及對策略解釋方式的說明。

場景 #1：在此場景中，我們正在從su中刪除所有功能，但 CAP_SETUID 和 CAP_SETGID 除外。

 ...
  subject /bin/su o
   ...
    -CAP_ALL
    +CAP_SETUID
    +CAP_SETGID

場景 #2：在此場景中，我們正在使用策略繼承。請注意，預設主題允許 CAP_NET_BIND_SERVICE 和 CAP_NET_RAW。在我們的ping主題中，我們正在刪除 CAP_NET_BIND_SERVICE，但由於我們正在從預設主題繼承（注意 o 主題模式在ping主題上不存在），我們仍然允許 CAP_NET_RAW。RBAC 系統不允許向預設主題授予重要功能，因此這只是一個示例。

 ...
  subject /
   ...
    -CAP_ALL
    +CAP_NET_RAW
    +CAP_NET_BIND_SERVICE
  subject /bin/ping
   ...
    -CAP_NET_BIND_SERVICE

審計和抑制：還可以對嘗試使用的功能進行審計，並抑制拒絕使用的功能。功能審計和抑制支援與正常功能規則相同的策略繼承規則。以下示例演示了審計 CAP_NET_RAW 的使用和抑制 CAP_NET_BIND_SERVICE 拒絕

 ...
  subject /
   ...
    -CAP_ALL
    -CAP_NET_BIND_SERVICE suppress
    +CAP_NET_RAW audit

有關可用功能的完整列表，請參閱：功能名稱和描述。請注意，你的特定版本的 Linux 核心可能不支援列出的所有功能。

資源限制

[編輯 | 編輯原始碼]

grsecurity 的 ACL 系統的一個功能是基於程序的資源限制。使用此功能，你可以限制程序可以佔用多少記憶體、多少 CPU 時間、可以開啟多少檔案以及可以執行多少程序等。在本節中，我們還將討論在 grsecurity 的 ACL 系統中實現的“偽”資源“RES_CRASH”，它有助於防止暴力破解利用嘗試，如果使用 PaX，則這是必需的。

單個資源規則遵循以下語法

<resource name> <soft limit> <hard limit>

此語法的示例將是

RES_NOFILE 3 3

這將允許程序最多開啟 3 個檔案（所有程序在某些時候都會開啟 3 個檔案描述符：stdin（標準輸入）、stdout（標準輸出）和 stderr（標準錯誤輸出））。

為了闡明軟限制和硬限制是什麼，軟限制是在程序執行時分配給它的限制。硬限制是程序可以透過以下方式提高限制的最大值。setrlimit(2)，除非它們具有 CAP_SYS_RESOURCE。在 RES_CPU 的情況下，當超過軟限制時，會不斷向程序傳送特殊訊號。當超過硬限制時，程序會被殺死。

不太熟悉 Linux 的人應該堅持設定檔案數量、地址空間限制和程序數量的限制。當然，你總是可以使用 學習模式 的 grsecurity 來為你設定資源限制。RES_CPU 資源是唯一接受時間作為限制的資源。時間預設為毫秒單位。你也可以在你的限制後面新增一個大小寫敏感的單位。

一些例子是

  • 100s – 100 秒
  • 25m – 25 分鐘
  • 65h – 65 小時
  • 2d – 2 天

其他資源要麼使用數字本身，要麼使用大小（以位元組為單位）。對於這些，你可以使用以下單位：K、M 和 G，例如

  • 2G – 20 億
  • 25M – 2500 萬
  • 100K – 10 萬

如果你不想對資源的軟限制或硬限制有任何限制，可以使用“unlimited”作為限制。這裡有一些額外的例子可以幫助你理解它是如何工作的

subject /bin/bash
       /               r
       /opt            rx
       /home           rwxcd
       /mnt            rw
       /dev
       /dev/grsec      h

       RES_CPU 25m 30m
       RLIMIT_AS 5M 5M
       RLIMIT_NPROC 2 2
       RLIMIT_FSIZE 5K 10K
...

有關接受的資源名稱和單位列表，請參閱 系統資源。

RES_CRASH

[edit | edit source]

此“假”資源限制透過使用名稱“RES_CRASH”來表達，並且具有以下語法

RES_CRASH <number of crashes> <amt. of time>

例如，如果你想允許程式每 30 分鐘崩潰一次，你可以使用以下內容

RES_CRASH 1 30m

當達到此閾值時會發生什麼？好吧，確保程序不再崩潰的唯一方法是阻止它執行。如果程序是普通使用者執行的 suid/sgid 二進位制檔案，我們將殺死所有該普通使用者的程序，並阻止他們以 RES_CRASH 資源的第二個引數中指定的時間登入。因此，對於上面的示例，使用者將被鎖定在系統之外 30 分鐘。如果程序不是 suid/sguid 二進位制檔案，我們只需在殺死該二進位制檔案的所有程序後，阻止該二進位制檔案再次執行 RES_CRASH 資源的第二個引數中指定的時間。

套接字策略

[edit | edit source]

RBAC 系統支援對機器上可以保留哪些本地 IP 地址和埠以及可以與哪些遠端主機和埠通訊的策略。這兩種不同的訪問分別抽象為繫結和連線規則。規則的語法為

  connect <IP/host>/<netmask>:<port/portrange> <socket type 1>... <socket type n> <proto 1>... <proto n>
  bind <IP/host>/<netmask>:<port/portrange> <socket type 1>... <socket type n> <proto 1>... <proto n>

  or:

  connect disabled
  bind disabled

“proto”可以是/etc/protocol中列出的任何協議名稱，也可以是“any_proto”來表示任何協議。“socket type”最常見的是“ip”、“dgram”或“stream”，但也可以是“raw_sock”、“rdm”或“any_sock”來表示任何套接字型別。這些規則的大多數引數都是可選的，特別是網路掩碼和埠或埠範圍。如果提供了埠，則至少需要提供 0.0.0.0/0 的 IP 地址。

與能力限制、資源限制和許多其他 RBAC 功能一樣，如果為給定主體省略套接字策略，則該主體被允許繫結或連線到系統通常允許的任何內容。但請注意，如果給出了連線規則，則還必須指定至少一個繫結規則。舊版本的gradm（在 2009 年 9 月 16 日釋出的 2.1.14 之前）將把未指定的規則視為“停用”規則，而新版本將在這些策略上生成錯誤。

Warning 與檔案物件和能力不同，套接字策略尚未實現策略繼承。因此，給定主體的套接字策略僅由該主體本身決定。

以下是一些示例規則

  subject /usr/bin/ssh o
 ...
  connect 192.168.0.0/24:22 stream tcp
  connect ourdnsserver.com:53 dgram udp

在此示例中，ssh被允許連線到 C 類 192.168.0.X 網路上的任何地方的 ssh 伺服器。它也被允許透過指定的主機進行 DNS 查詢。主機名在啟用 RBAC 系統時解析。

  subject /usr/bin/nc o
 ...
  bind 0.0.0.0/0:1024-65535 stream tcp
  connect 22.22.22.22:5190 stream tcp

在此示例中，netcat被允許在任何本地介面上的埠 1024 到 65535 上監聽 TCP 連線。它還能夠連線到 22.22.22.22 主機的 TCP 埠 5190。

  subject /bin/strange o
 ...
  bind disabled
  connect 192.168.1.5:6000-6006 stream tcp

此示例說明了如何停用繫結但仍然指定連線規則，或者相反，停用連線並僅指定繫結規則。

如你從上面的示例中看到的，你可以為給定主體設定任意數量的套接字策略，並且正如你在下面將要閱讀的那樣，套接字策略有一些強大的擴充套件。

每個介面的套接字策略

[edit | edit source]

諸如

bind eth1:80 stream tcp
bind eth0#1:22 stream tcp

的規則是允許的，這使你能夠將特定的套接字規則繫結到單個介面（或者透過使用下面提到的反轉規則，將所有規則繫結到除了一個介面之外的所有介面）。虛擬介面由 <ifname>#<vindex> 語法指定。如果指定了介面，則不能為該規則指定 IP/網路掩碼或主機。

反轉套接字策略

[edit | edit source]

諸如

connect ! www.google.com:80 stream tcp

是允許的，這使你能夠指定程序可以連線到任何內容，除了使用流 TCP 套接字連線到 www.google.com 的埠 80。反轉套接字匹配也適用於繫結規則。

PaX 標誌

[edit | edit source]

在 RBAC 系統的較新版本中，PaX 標誌已從單個字母主體模式更改為更類似於能力在策略中處理的方式。因此，現在可以透過在主體範圍內新增 +PAX_<feature> 或 -PAX_<feature> 來完全控制任何給定主體的 PaX 標誌，以開啟或關閉 PaX 標誌。有關可用 PaX 標誌的完整列表，請參閱：PaX 標誌。

匹配流程

[edit | edit source]

系統上的每個程序都具有與之關聯的角色和主體。本節介紹如何將程序與角色和主體匹配，以及如何針對它們使用的物件和能力計算匹配。瞭解匹配流程對於手動建立策略是必要的。

角色層次結構

[edit | edit source]

在確定程序的角色時，RBAC 系統根據以下角色層次結構進行匹配，從最具體到最不具體

 user -> group -> default

使用者角色和組角色都允許具有role_allow_ip屬性。當分別檢查 UID 或 GID 與使用者或組角色的匹配時，role_allow_ip屬性將發揮作用。想象一下以下策略

role user1 u
role_allow_ip 192.168.1.5
...

如果有人試圖從除 192.168.1.5 之外的任何 IP 地址登入到機器作為 user1，他們將不會被分配 user1 角色。然後，匹配系統將回退到嘗試找到可接受的組角色，或者如果沒有找到，則回退到預設角色。

主體/物件層次結構

[edit | edit source]

主體和物件的層次結構涉及匹配最具體的路徑名而不是更不具體的路徑名。因此，如果存在/bin物件，並且存在/bin/ping物件，並且程序試圖讀取/bin/ping，那麼/bin/ping物件將是匹配的物件。如果改為訪問/bin/su，那麼/bin將匹配。

然而，從最具體的路徑名到最不具體的路徑名的路徑並非線性，特別是在使用策略繼承的主題的情況下。想象一下以下策略

role user1 u
  subject /
    / r
    /tmp rwcd
    /usr/bin rx
    /root r
    /root/test/blah r
   ...
  subject /usr/bin/specialbin
    /root/test rw
   ...

如果/usr/bin/specialbin訪問了/root/test/blah，它將無法寫入它。原因是，當從最具體到最不具體地查詢給定路徑時（這涉及剝離每個尾隨路徑元件並嘗試匹配所得路徑名），匹配演算法將在當前主體繼承的每個主體中查詢（按從最具體到最不具體的順序）。在本例中，該演算法發現/usr/bin/specialbin主體中不存在/root/test/blah的物件，因此在檢查/的主體時，它找到了/root/test/blah物件，從而導致只讀許可權。

當從最具體到最不具體時，像/home/*這樣的萬用字元物件被視為比/home/blah更不具體（如果請求的訪問是針對/home/blah）。萬用字元物件按照它們在 RBAC 策略中列出的順序進行匹配。因此，在以下示例中

role user1 u
  subject /
     / r
     /home r
     /home/* r
     /home/test* rw
    ...

如果一個程序訪問了/home/testing/somefile，它將只能讀取它，因為/home/*規則排在首位。這很可能是策略編寫者沒有預期的行為（因為/home/test*規則永遠不會匹配），所以應該將/home/test*物件交換到/home/*物件所在的行上。

功能層次結構

[edit | edit source]

在確定是否授予功能時，RBAC 系統從最具體的主題到最不具體的主題（在策略繼承的情況下）工作。該路徑上第一個提到所討論功能的主題是匹配的主題。為了說明

role user1 u
  subject /
   ...
    -CAP_ALL
    +CAP_NET_BIND_SERVICE
  subject /bin
   ...
    -CAP_NET_BIND_SERVICE
  subject /bin/su
   ...
    +CAP_SETUID
    +CAP_SETGID

在這個例子中，/bin/su只能使用 CAP_SETUID 和 CAP_SETGID。對 CAP_NET_BIND_SERVICE 的查詢將回退到 /bin 主題，因為 /bin/su 從它繼承而來，並且沒有顯式列出 CAP_NET_BIND_SERVICE 的規則。/bin 主題指定禁止使用 CAP_NET_BIND_SERVICE。與另一個功能（例如 CAP_SYS_ADMIN）匹配將最終回退到 / 主題，在那裡它將匹配 -CAP_ALL 並被拒絕。

策略建議

[edit | edit source]

嘗試從預設主題中刪除儘可能多的功能。刪除得越多，root 就越接近於充當普通使用者。但是，您刪除的功能越多，您將需要為需要這些功能的程式建立的主題就越多。RBAC 系統將強制執行從所有預設主題中刪除最低級別的功能。

使用完整的系統學習。它將生成比您手動生成的更好的策略。確保您充分利用 /etc/grsec/learn_config 檔案來指定您要保護的特定於您系統的檔案和目錄。gradm將完成為訪問或修改重要資料的程序建立特權邊界的大部分工作。

管理程式（如 shutdown 或 reboot）應該需要身份驗證，而不是讓每個人都擁有執行它們的許可權。

始終檢查您的核心日誌。RBAC 系統在每個核心日誌中提供大量的可讀資訊。特別重要的是分配給導致警報的程序的角色和主題。如果您認為警報與您對策略的期望不符，請確保角色和主題確實匹配。如果它們不匹配，那麼您可能在阻止應用適當角色的 role_allow_ip 規則方面存在問題。

熟悉 Linux 的功能及其涵蓋的內容。您可以在這裡找到它們的完整列表：功能名稱和描述.

在您完全瞭解它如何形成給定主題的策略之前，請避免使用策略繼承。即使那樣，也要謹慎使用它，通常將其保留在預設主題配置為最低許可權、沒有可讀/可寫/可執行物件且沒有功能的情況下。

儘可能避免對物件授予寫入和執行許可權。這會讓潛在的攻擊者能夠執行任意程式碼。類似於 PaX 如何防止在給定程序的地址空間內執行任意程式碼，您在建立策略時的目標之一也是防止這種情況在檔案系統中發生。

在使用抑制 ('s') 物件標誌時要小心，尤其是在將其應用於 / 以忽略程式實際上不需要正常執行的訪問時。glibc 或主題使用的另一個庫的更改可能會導致應用程式以難以除錯的方式失敗（除非您的第一步是刪除抑制標誌）。

示例策略

[edit | edit source]

以下是隨附的示例策略gradm安裝

role admin sA
subject / rvka
        / rwcdmlxi

role default G
role_transitions admin
subject /
        /               r
        /opt            rx
        /home           rwxcd
        /mnt            rw
        /dev
        /dev/grsec      h
        /dev/urandom    r
        /dev/random     r
        /dev/zero       rw
        /dev/input      rw
        /dev/psaux      rw
        /dev/null       rw
        /dev/tty?       rw
        /dev/console    rw
        /dev/tty        rw
        /dev/pts        rw
        /dev/ptmx       rw
        /dev/dsp        rw
        /dev/mixer      rw
        /dev/initctl    rw
        /dev/fd0        r
        /dev/cdrom      r
        /dev/mem        h
        /dev/kmem       h
        /dev/port       h
        /bin            rx
        /sbin           rx
        /lib            rx
        /usr            rx
# compilation of kernel code should be done within the admin role
        /usr/src        h
        /etc            rx
        /proc           rwx
        /proc/slabinfo  h
        /proc/kcore     h
        /proc/modules   h
        /proc/sys       r
        /root           r
        /tmp            rwcd
        /var            rwxcd
        /var/tmp        rwcd
        /var/log        r
# hide the kernel images and modules
        /boot           h
        /lib/modules    h
        /etc/grsec      h
        /etc/ssh        h

# if sshd needs to be restarted, it can be done through the admin role
# restarting sshd should be followed immediately by a gradm -u
        /usr/sbin/sshd

        -CAP_KILL
        -CAP_SYS_TTY_CONFIG
        -CAP_LINUX_IMMUTABLE
        -CAP_NET_RAW
        -CAP_MKNOD
        -CAP_SYS_ADMIN
        -CAP_SYS_RAWIO
        -CAP_SYS_MODULE
        -CAP_SYS_PTRACE
        -CAP_NET_ADMIN
        -CAP_NET_BIND_SERVICE
        -CAP_NET_RAW
        -CAP_SYS_CHROOT
        -CAP_SYS_BOOT

#       RES_AS 100M 100M

#       connect 192.168.1.0/24:22 stream tcp
#       bind    0.0.0.0 stream dgram tcp udp

# the d flag protects /proc fd and mem entries for sshd
# all daemons should have 'p' in their subject mode to prevent
# an attacker from killing the service (and restarting it with trojaned
# config file or taking the port it reserved to run a trojaned service)

subject /usr/sbin/sshd dpo
        /               h
        /bin/bash       x
        /dev            h
        /dev/log        rw
        /dev/random     r
        /dev/urandom    r
        /dev/null       rw
        /dev/ptmx       rw
        /dev/pts        rw
        /dev/tty        rw
        /dev/tty?       rw
        /etc            r
        /etc/grsec      h
        /home
        /lib            rx
        /root
        /proc           r
        /proc/kcore     h
        /proc/sys       h
        /usr/lib        rx
        /usr/share/zoneinfo r
        /var/log
        /var/mail
        /var/log/lastlog        rw
        /var/log/wtmp           w
        /var/run/sshd
        /var/run/utmp           rw

        -CAP_ALL
        +CAP_CHOWN
        +CAP_SETGID
        +CAP_SETUID
        +CAP_SYS_CHROOT
        +CAP_SYS_RESOURCE
        +CAP_SYS_TTY_CONFIG

subject /usr/X11R6/bin/XFree86
        /dev/mem        rw

        +CAP_SYS_ADMIN
        +CAP_SYS_TTY_CONFIG
        +CAP_SYS_RAWIO

        -PAX_SEGMEXEC
        -PAX_PAGEEXEC
        -PAX_MPROTECT

subject /usr/bin/ssh
        /etc/ssh/ssh_config r

subject /sbin/klogd
        +CAP_SYS_ADMIN

subject /sbin/syslog-ng
        +CAP_SYS_ADMIN

subject /usr/sbin/cron
        /dev/log rw

subject /bin/login
        /dev/log rw
        /var/log/wtmp w
        /var/log/faillog rwcd

subject /sbin/getty
        /var/log/wtmp w

subject /sbin/init
        /var/log/wtmp w

以下是一個涵蓋以下行為的完整使用者角色策略cvs-pserver當以非 root cvs 使用者身份執行時，提供匿名只讀 CVS 儲存庫訪問許可權。

role cvs u
   subject /
      /     h
      -CAP_ALL
      connect   disabled
      bind      disabled

   subject /usr/bin/cvs
      /
      /etc/fstab         r
      /etc/mtab          r
      /etc/passwd        r
      /proc/meminfo      r
      /dev/urandom       r
      /dev/log           rw
      /dev/null          rw
      /home/cvs          r
      /home/cvs/CVSROOT/val-tags  rw
      /home/cvs/CVSROOT/history   ra
      /tmp               rwcd
      /var/lock/cvs      rwcd
      /var/run/.nscd_socket       rw
      /proc/sys/kernel   r
      /var/run

以下是無許可權 sshd 帳戶所需的一切

role sshd u
   subject /
      /  h
      /var/run/sshd r
      -CAP_ALL
      bind disabled
      connect disabled
下一頁： 應用程式特定設定 | 上一頁： 故障排除
主頁： Grsecurity
檢索自 "https://wikibook.tw/w/index.php?title=Grsecurity/The_RBAC_System&oldid=3451562"
華夏公益教科書