跳转到内容

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://wikibooks.cn/w/index.php?title=Grsecurity/The_RBAC_System&oldid=3451562"
华夏公益教科书