Linux内核安全模块详解：客体类别和操作

不同的客体类别有不同的操作。回顾一下自主访问控制，文件上的操作是读、写和执行，进程间通信上的操作是读和写，密钥上的操作是读、写、搜索、链接、查看属性和设置属性。为了和SELinux类型增强机制中的类型相区别，本节用“客体类别”这个词汇来指代不同的客体种类，如文件、进程间通信、密钥等。总的来说，自主访问控制中的操作类型不多，易于掌握。

SELinux设计的操作极为复杂。首先，SELinux设计了比自主访问控制多得多的客体类别其次，SELinux在每个客体类别上一般又定义了几十种此客体类别专有的操作。SELinux这么做的本意是因为传统UNIX在操作类型的设计上过于简单，无法区分细微的语义差别。但是过犹不及，如此细密的操作分类实在是让人难以掌握。

本节所列举的客体类别和客体类别上的操作来自SELinux策略文件“access_vectors”。在阅读代码后，作者发现access_vectors中的内容和内核SELinux代码并不完全符合。文件access_vectors中多了一些没有用到的定义，而且作者判断这些多余的定义未来也不会用到。这是SELinux复杂的另一个来源——不合乎逻辑的、冗余的、无用的定义！

下面逐一列举SELinux在不同客体类别上的操作。

1.进程

简单地说，进程就是程序的一次执行。与之相关的第一个操作就是执行，除了执行代码段里的代码外，还可能执行堆上、栈上、甚至匿名映射内存中的代码。其次，进程是操作系统的调度单位。进程可以“繁殖”，所以有父子关系，子进程可以和父进程共享某些信息；进程之间可以收发信号，可以跟踪或被跟踪；为了完成这些复杂的操作，进程还是一个资源的集合，进程有进程号、进程组号、进程会话号、调度优先级等等。最后，SELinux在进程中增加了安全上下文，这部分信息的存取也是进程操作的一部分。

（1）执行

●execheap在堆上执行

●execmem在匿名内存映射上或在私有文件映射上执行

●execstack在栈上执行

●ptrace跟踪进程的执行

●noatsecure关闭参数ATSECURE的设置

内核在exec系统调用中可能会设置一个参数ATSECURE传递到用户态，由libc(loader)执行一些安全操作。

（2）繁殖

●fork通过fork()或clone()创建新进程

●share允许父子进程共享一些进程数据，比如文件系统

当调用clone()时，如带有CLONE_FS标志，父子进程共享同样的文件系统信息，包括根当前工作目录、umask。父或子进程调用chroot、chdir、umask时就会影响到另外的进程。

（3）资源

●getcap读取进程的能力集合

●setcap设置进程（自己）的能力集合

●getpgid读取进程的组id

●setpgid设置进程的组id

●getsession读取进程的会话id

●getsched读取进程的调度信息

●setsched设置进程的调度信息

●rlimitinh可以从父进程继承rlimit信息

●setrlimit修改进程的rlimit信息

（4）信号

●siginh可以从父进程继承信号状态信息

●sigchld允许发送SIGCHLD信号

●sigkill允许发送SIGKILL信号

●sigstop允许发送SIGSTOP信号

●signal允许发送其他信号

●signull允许探知进程的存在

（5）SELinux

下面要讲述的操作和进程的安全上下文有关。SELinux为了精细地区分不同场景，为主体（进程）设计了多个安全上下文。所以在介绍具体操作之前，有必要先介绍一下进程上不同的安全上下文。

下面先解释一下进程的各安全上下文的含义：

1）以前的安全上下文（osid）

变化之前的进程安全上下文。

2）进程安全上下文（sid）

这是进程最基本的安全上下文，标记了进程的安全属性。

3）执行安全上下文（exec_sid）

当进程执行execve系统调用时，进程的安全上下文可能会发生变化。一种情况是，进程的新安全上下文来自进程的旧安全上下文和被执行文件的安全上下文进行运算后的结果。另一种情况是，来自进程的“执行安全上下文”。此项操作用于设置进程的执行安全上下文。

4）文件安全上下文（create_sid）

当进程创建文件时，文件的安全上下文是：

i）如果进程的文件系统安全上下文不为空，那么文件的安全上下文的值就是进程的文件系统安全上下文。

ii）如果进程的文件系统安全上下文为空，那么文件的安全上下文就是用进程的安全上下文和文件所在目录的安全上下文进行计算的结果。

5）密钥安全上下文（keycreate_sid）

创建密钥时，如果进程有密钥上下文，新密钥的安全上下文就用进程的密钥上下文；否则新密钥的安全上下文就用进程的安全上下文。

6）套接字安全上下文（sockcreate_sid）

进程创建套接字时，如果进程有套接字安全上下文，新套接字的安全上下文就用进程的套接字安全上下文；否则，新套接字安全上下文来自运算的结果。

这些安全上下文可以通过/proc/[pid]/attr目录下的若干伪文件接口设置和查看

现在终于可以介绍进程上的和SELinux相关的操作了。进程查看/proc/[pid]/attr下各个伪文件需要getattr操作许可。进程设置/proc/[pid]/attr下的伪文件，则视文件不同，需要不同的操作许可。

●getattr获取进程的安全上下文

对/proc/[pid]/attr下所有文件的读取都需要此项权限。

●setcurrent通过修改/proc/self/attr/current文件内容更改当前进程安全上下文

动态改变一个进程的安全上下文必须同时满足下面3个条件：

a）只能改自己的。

b）有策略允许进程具有setcurrent操作许可。

c）有策略允许进程的安全上下文改变为新的值。

●setexec设置进程执行安全上下文

●setfscreate设置进程文件系统安全上下文

●setkeycreate设置进程密钥安全上下文

●setsockcreate设置进程套接字安全上下文

●dyntransition动态转化到一个新域

dyntransition影响的是进程以setcurrent方式（写/proc/self/attr/current）得到的新的安全上下文。

●transition在执行exec()时，转化到一个新安全上下文

transition影响的是进程调用execve后的安全上下文。

2.文件

UNIX的哲学是万物皆文件。文件的类别有：普通文件、设备文件、socket文件、链接文件、管道文件等。

首先，文件是信息的载体，所以文件可以被创建、读、写、添加；其次，文件不仅包含存储于其中的数据，还关联一些所谓的元数据，比如创建时间、属主、数据大小等。这些元数据存储在文件属性中，读写元数据的操作就是getattr和setattr；当有多个进程需要同时操作一个文件时，就有了同步的需求，因此有了lock；文件还可能关联特殊的操作，那些特殊的操作都被归于ioctl；文件都关联到某个目录之下，相关的操作就有删除、改名、移动；文件可以被执行，一个不常见的用法是执行的同时改变文件内容。

（1）文件的共有操作

1）基本操作

●open打开文件。

●create创建文件。

●ioctl在文件上运行ioctl系统调用。

●lock在文件上设置或删除锁。

2）数据操作

●read读取文件内容。

●write写入文件内容。

●append在文件尾添加数据。

3）元数据操作

●getattr读取文件属性。

●setattr设置文件属性。

4）目录相关

●unlink删除文件（实际上删除的是hard link）。

●link创建硬链接（hard link）。

●rename文件改名。

5）执行操作

●execute执行文件。

●execmod执行文件，同时修改文件。

6）SELinux相关操作

●relabelfrom改变文件的安全上下文，使其不再是现在的值。

●relabelto改变文件的安全上下文，使其改变到新的值。

7）其他操作

●swapon^*：把文件用作操作系统swap区。这个操作似乎没有用到。在SELinux代码中没有看到这个操作许可起任何作用，但是它还存在，可能是在SELinux的演进过程中，它的功能被别的操作许可替代了，但是它本身又没有被删除干净。下面还有很多类似的操作许可，作者一律在操作后面加注“^*”。

●quotaon：设置quota。

●mounton^*：把文件作为一个挂载点

（2）不同的文件子类别

SELinux将文件分成不同的子类别：

●普通文件。

●目录文件。

●字符设备文件。

●块设备文件。

●套接字文件。

●链接文件。

●管道文件。

从逻辑上讲，上一节所列出的应该是在所有文件子类别上都可以进行的操作，但是显然不是这样的，像quotaon这种操作对套接字文件是没有意义的。SELinux在文件操作上的这种设计有些奇怪，分出了许多文件子类别，但又没有将文件操作随之细分。如果都不细分，也可以，但是SELinux又偏偏在普通文件和目录文件上增加了专有的操作，下面看一下。

1）普通文件

普通文件增加的操作类型都和执行有关。

●execute_no_trans：执行（exec）文件后进程的安全上下文不变。execute负责的是文件打开时的许可，execute_no_trans和entrypoint负责的是进程执行文件后进程的安全上下文的值。

●entrypoint：执行（exec）文件后进程安全上下文中的类型部分转换为新值。

2）目录

目录额外操作是：

●add_name：在目录中增加文件或子目录。

●remove_name：在目录中删除文件或子目录。

●reparent：更改父目录。

●search：搜索目录。Linux系统中全路径名又被称为路径（path）。经过的各级目录就涉及这个操作许可。把search理解为通过就清楚了。

●rmdir：删除目录。

（3）文件相关的其他客体

1）文件描述符

在某些情况下，进程间可以传递文件描述符。SELinux定义了一个客体类别--文件描述符，其上只有一个操作——“use”。

2）文件系统

文件系统的操作如下所示。

以下三个操作和挂载文件系统相关：

●mount：挂载文件系统。

●remount：重新挂载文件系统。

●unmount：卸载文件系统。

以下两个操作和文件系统的配额（quota）相关：

●quotamod：修改配额数据。

●quotaget：读取配额数据。

以下操作和文件系统属性相关：

●getattr：读取文件系统属性数据。

以下四个操作和SELinux相关：

●relabelfrom：文件系统的安全上下文不再是现在的值。

●relabelto：文件系统的安全上下文改变到新的值。

●transition^*

●associate：限定文件系统中文件可用的安全上下文的值。

3.套接字（socket）

UNIX的哲学是“万物皆文件”。但是起源于BSD的套接字打破了这个哲学。等到UNIX的捍卫者想要将套接字统一进文件时，为时已晚 ^[7] ，程序员已经熟悉了套接字，改不回来了。

从安全的角度考虑，UNIX上原生的套接字确实有些问题。UNIX在套接字上几乎没有访问控制。作者只能查到两处：一处是只允许代表root用户的进程绑定（bind）特权端口，即tcp和udp的端口号在1024以下的端口；另一处是发生在UNIX本地域的套接字操作中，服务器端bind操作会创建一个套接字文件，在客户端connect操作中会判断客户进程对此套接字文件是否有写许可。但是此处的套接字文件只是一种文件，并不是套接字。

SELinux虽然弥补了这一缺失，却矫枉过正了。它定义的套接字子类别过多，各类别上的操作也过细。

和文件一样，套接字也有很多种，它们有一些共有的操作许可，其中有一些和文件的一样如：ioctl、read、write、create、getattr、setattr、lock、relabelfrom、relabelto、append，还有一些是套接字特有的，如：bind、connect、listen、accept、getopt、setopt、shutdown、recvfrom、sendto、recv_msg、send_msg、name_bind。

（1）套接字与文件共有的操作许可

UNIX的哲学“万物皆文件”，并非凭空刻意为之。套接字中有很多和文件相同的操作类型SELinux让套接字和文件共享一些操作类型，但是做得有些生硬，一些对套接字没有意义的操作类型也混了进来。

以下是套接字的基本操作：

●create创建套接字

●ioctl^*

●lock^*

以下操作与数据收发相关：

●read自套接字读取消息。

●write向套接字发送消息。

●append^*。

以下操作与套接字的地址相关：

●getattr读取套接字当前绑定地址（getsockname），或者读取连接端套接字地址（getpeername）。

●setattr^*。

以下操作与SELinux相关：

●relabelfrom改变套接字的安全上下文，使其不再是现在的值。只在tun_socket中用到。

●relabelto改变套接字的安全上下文，使其变为新值。

（2）套接字特有操作许可

以下操作与连接相关：

●bind对套接字执行系统调用bind

●name_bind绑定套接字到特权端口

Linux系统为网络服务进程定义了一个端口范围，绑定范围外端口需要此项操作许可，关于端口范围可以查询/proc/sys/{ipv4,ipv6}/ip_local_port_range文件。

●listen对套接字执行系统调用listen

●accept对套接字执行系统调用accept

●connect对套接字执行系统调用connect

以下操作与套接字属性相关：

●getopt对套接字执行系统调用getsockopt

●setopt对套接字执行系统调用setsockopt

以下操作与套接字的数据收发相关：

●recvfrom自套接字读取数据包。只被udp_socket、tcp_socket、rawip_socket使用，即仅适用于主机间通信。

●sendto向套接字发送数据包。只被UNIX套接字使用，即仅适用于同一主机内进程间通信。

●recv_msg^*

●send_msg^*

以下为其他操作：

●shutdown对套接字执行系统调用shutdown

（3）不同的套接字类型上的特有操作

1）tcp_socket

在客体类别“tcp_socket”上的操作包含上面列出的所有套接字与文件共有的操作和所有套接字的特有操作，此外，tcp_socket还包含如下操作：

●connectto^*

●newconn^*

●acceptfrom^*(www.xing528.com)

●node_bind将套接字绑定到某个网络地址上

主机可以有多个网络地址，如127.0.0.1是回送地址，192.168.1.1是内部局域网地址。这个操作限定绑定到某个地址之上。

●name_connect socket连接到某个网络端口上

赋予端口安全上下文，限制对端口的连接操作。

2）udp_socket

客体类别udp_socket的操作既包含所有套接字的共有操作，还包含如下操作

●node_bind将socket绑定到某个网络地址上

3）rawip_socket

客体类别rawip_socket的特有操作如下：

●node_bind将socket绑定到某个网络地址上

4）netlink_socket

此套接字类别没有特有操作。

5）netlink_route_socket

客体类别netlink_route_socket的特有操作如下：

●nlmsg_read读取信息

●nlmsg_write写入信息

6）netlink_firewall_socket

客体类别netlink_firewall_socket的特有操作如下：

●nlmsg_read读取信息

●nlmsg_write写入信息

7）netlink_tcpdiag_socket

客体类别netlink_tcpdiag_socket的特有操作如下：

●nlmsg_read读取信息

●nlmsg_write写入信息

8）netlink_nflog_socket

此套接字类别没有特有操作。

9）netlink_xfrm_socket

客体类别netlink_xfrm_socket的特有操作如下：

●nlmsg_read读取信息

●nlmsg_write写入信息

10）netlink_selinux_socket

此套接字类别没有特有操作。

11）netlink_audit_socket

客体类别netlink_audit_socket的特有操作如下：

●nlmsg_read读取信息

●nlmsg_write写入信息

●nlmsg_relay将用户态audit消息转发给audit服务

●nlmsg_readpriv列出audit配置规则

●nlmsg_tty_audit控制tty审计信息

12）netlink_ip6fw_socket

客体类别netlink_ip6fw_socket的特有操作如下：

●nlmsg_read读取信息

●nlmsg_write写入信息

13）netlink_dnrt_socket

此套接字类别没有特有操作。

14）netlink_kobject_uevent_socket

此套接字类别没有特有操作。

15）packet_socket

此套接字类别没有特有操作。

16）key_socket

此套接字类别没有特有操作。

17）unix_stream_socket

客体类别“unix_stream_socket”的特有操作如下：

●connectto连接到服务socket

●newconn^*

●acceptfrom^*

18）unix_dgream_socket

此套接字类别没有特有操作。

19）appletalk_socket

此套接字类别没有特有操作。

20）dccp_socket

客体类别dccp_socket的特有操作如下：

●node_bind将socket绑定到某个网络地址上

●name_connect连接socket到某个地址

21）tun_socket

客体类别“tun_socket”的特有操作如下：

●attach_queue附加一个新队列

SELinux不厌其烦地在套接字上细分出子类别，其实有些过犹不及。

4.进程间通信

进程间通信（Inter-Process Communication，IPC）包括信号灯（Semaphore）、消息队列（Message Queue）、共享内存（Shared Memory）。它们具有一些共同的操作许可：

（1）进程间通信的共有操作

●create创建

●destroy删除

●getattr读取属性

●setattr设置属性

●associate获取IPC对象ID

在系统调用semget、msgget、shmget中，在获取IPC对象前，SELinux会判断associate操作许可。

●read读取消息/内容

●write写入消息/内容

●unix_read读取

●unix_write写入

unix_read和unix_write是指传统的UNIX中规定的读写操作。它们和打开一个进程间通信对象时给出的操作模式相联系，是只读、只写或读写方式。read和write的功能也是读和写，其实与unix_read和unix_write是有重合的。下面看代码：

上面的代码首先调了进程间通信通用的ipcperms，然后调了共享内存专有的security_ shm_shmat。先来看ipcperms。

总结一下，ipcperms会间接调用ipc_has_perm来判断unix_read和unix_write操作许可。

下面看security_shm_shmat，它会调用SELinux的钩子函数selinux_shm_shmat:

总结一下，security_shm_shmat会间接调用ipc_has_perm来判断read和write操作许可。

在SELinux代码中，有些暗含读语义或写语义的系统调用中也会判断read和write操作，例如在系统调用semctl中，当参数cmd是GETVAL或GETALL时，SELinux会判断read操作许可。

（2）各种进程间通信上的特有操作

在信号灯上无特有操作；在消息队列上有一个特有操作enqueue，含义是发送消息到消息队列；在共享内存上的特有操作是lock，含义是加锁或解锁共享内存。

（3）消息队列中的消息

在消息队列的消息本身也带有安全上下文。

对消息队列中的消息，SELinux提供了额外的操作许可。

●receive从队列读取消息

●send向队列写入消息

细分析SELinux代码你会发现，它在有的地方实在是罗嗦。以消息队列为例，为了获得消息队列对象，应用程序要调用系统调用msgget，SELinux会根据传入参数msgflg检查unix_read和unix_write，还会判断associate。然后应用程序调用msgrcv或msgsnd时，SELinux会先判断unix_read和unix_write，然后判断read和write，最后还要在消息上判断receive和send。下面看一下代码。

这里的associate函数指针指向函数msg_security。

security_msg_queue_associate会调用SELinux的钩子函数。

以发送为例：

security_msg_queue_msgsnd会调用SELinux的钩子函数selinux_msg_queue_msgsnd:

5.网络

SELinux对网络对象的标记比较复杂，目前大概有4套体系共存：通过SELinux网络策略标记、通过标签化的IP协议头（CIPSO）标记 ^[8] 、通过IPSEC标记、通过iptable的secmark标记。其中，标签化网络形式又支持在IP协议头没有标记的情况下，根据环境信息（IP地址、端口号）标记网络，这又和通过SELinux网络策略标记重合。

为什么SELinux中会有这么多套体系同时作用于网络类的客体呢？作者认为原因是SELinux在如何为网络类客体设计安全上下文上还不成熟。

为了便于理解，下面只介绍第一个方案。先思考一下网络对象是由什么组成的？首先是节点（node），节点由IP地址限定。其次，在节点上有一个进程在收发网络包，这被定义为“peer”然后，当网络包到达本地端时，它要经过网卡，这被定义为网络接口“netif”。最后，当我们将控制的粒度细化时，对每一个网络包都可以实施不同的访问控制，网络包就被定义为“packet”

（1）网络节点（node）

客体类别“node”上有以下操作。这些操作不是同时加入的。在“recvfrom”和“sendto”两个操作加入内核后，其他的操作就不再使用了。

●dccp_recv^*

●dccp_send^*

●tcp_recv^*

●tcp_send^*

●udp_recv^*

●udp_send^*

●rawip_recv^*

●rawip_send^*

●enforce_dest^*

●recvfrom接收来自网络节点的数据包

●sendto发送数据包到网络节点

（2）网络接口（netif）

客体类别“netif”上有以下操作。这些操作不是同时加入的。在“ingress”和“egress”两个操作加入内核后，其他的操作就不再使用了。

●tcp_recv^*

●tcp_send^*

●udp_recv^*

●udp_send^*

●rawip_recv^*

●rawip_send^*

●dccp_recv^*

●dccp_send^*

●ingress通过网络接口接收数据包

●egress通过网络接口发送数据包

（3）peer

客体类别“peer”的引入简化了SELinux的逻辑 ^[9] 。其上有一个操作：

●recv接收消息

（4）packet

客体类别“packet”指网络上传输的数据包。其上有五个操作，可分为两类。

1）基本

●send发送

●recv接收

●forward_in向内转发

●forward_out向外转发

2）SELinux相关

●relabelto

标记SELinux的安全上下文。奇怪的是，没有relabelfrom。

6.系统（system）

文件可以有多个，套接字也可以有多个，但系统类别的客体实例是全局性的，只有一个。system类型之上的操作有获取ipc信息（ipc_info）、syslog相关操作（syslog_console、syslog_ mod、syslog_read）和内核模块相关操作（module_request）。虽然叫系统，却只涉及寥寥几个操作许可，让人感到有些奇怪。

（1）进程间通信

●ipc_info读取系统ipc信息

具体来说，当系统调用msgctl的cmd参数为IPC_INFO或MSG_INFO时，或当系统调用semctl的cmd参数为IPC_INFO或SEM_INFO时，或当系统调用shmctl的cmd参数为IPC_INFO或SHM_INFO时，SELinux会判断此操作许可。

（2）syslog

以下几个操作都和系统调用syslog相关。

●syslog_read：读取kernel日志消息。

●syslog_mod：清空kernel消息缓冲区。

●syslog_console：控制kernel日志打印到控制台。

（3）module

●module_request：加载内核模块。

7.安全（security）

SELinux的设计者希望设计出一个完备的系统，对于+自身的管理也要纳入到SELinux的管理体系中。所以SELinux引入了新的客体类别——安全。在安全类别上的操作都和SELinux自身管理有关。

这里有一个问题：SELinux是如何管理自身的呢？因为Linux内核对增加系统调用非常慎重，所以SELinux没有引入新的系统调用，而是构建了一个文件系统——selinuxfs。在Linux上增加文件系统是很容易的。用户态进程通过读写selinuxfs上的文件来实现对SELinux的管理。相应地，SELinux规定了以下操作：

●check_context：查看安全上下文是否合法。

●compute_av：根据源安全上下文、目的安全上下文、客体类型计算访问许可。

●compute_create：输入源安全上下文、目的安全上下文、客体类型，根据type_transition策略计算新安全上下文。

●compute_member：输入源安全上下文、目的安全上下文、客体类型，根据type_member策略计算新安全上下文。

●compute_relabel：输入源安全上下文、目的安全上下文、客体类型，根据type_change策略计算新安全上下文。

●compute_user：输入安全上下文和用户名，计算新的安全上下文。

●load_policy：加载安全策略。

●setbool：改变SELinux布尔变量值。

●setcheckreqprot：修改SELinux变量checkreqprot值。在执行mmap和mprotect系统调用时，若值为0，执行来自内核的检验方法，若值为1，执行来自应用的检验模式。内核的检查方法是将read和exec联系起来。

●setenforce：改变SELinux的enforcement状态（permissive或enforcing）。

●setsecparam：改变AVC参数。

8.能力

能力是进程的特权。从逻辑上讲，能力是进程的一种资源。如果能力可以是一种客体，那么进程的内存大小、进程的描述符数量、文件占用的磁盘块数量、用户同时拥有的进程数量都可以是客体。

如果把能力作为一种客体，那么对能力的操作应该是添加、删除、查看。但是这样设计没有任何意义。因为在execve系统调用中不会区分添加和删除；在capset系统调用中只允许删除能力，而删除能力本身不应被限制；查看进程的能力也没有什么安全问题，没有限制的必要。

SELinux要套用它的标准逻辑“主体操作客体”。所以SELinux将能力定义为一种客体类别，将能力上的操作定义为具体的能力，如cap_chown。这种设计带来了三个问题：

（1）具体的能力怎么能成为能力的操作呢？这不合逻辑。

（2）进程是主体，能力是客体，能力本身就是进程的一个属性，主体和客体的安全上下文总是一样的。

（3）SELinux为能力设计了两个客体类别：capability和capability2。capability对应前32个能力，capability2对应后32个能力。

SELinux内部用一个比特表示一个操作，用一个32位整数表示在某个客体类别上的全部操作类型。如进程上的操作一共有30个，目录上的操作一共有25个，都没有超过32。但是在能力上，原有代码的数据结构无法表示，为了解决这个问题，SELinux就多引入了一个能力相关的客体类别capability2。

能力只有一个，capability和capability2在语义上没有区别，这种设计实在算不上优雅。

9.用户态客体

Linux系统中还有一些客体存在于用户态。如数据库，在内核眼里只有文件，没有表（table）、记录（record）之类。所以对数据库的控制自然就应该由用户态服务进程来实施。但是，相关的策略仍然被内核掌控，整个系统只有一个策略库，这个策略库存储在内核内存之中，由内核的安全服务器负责管理。那些用户态服务进程所做的工作就是查询策略库确定对用户态客体的操作是否允许。

SELinux的用户态客体包括数据库类型（db_database、db_table、db_procedure、db_column、db_tuple……）、X-Window相关类型（x_drawable、x_screen、x_gc、x_font、x_colormap……）、dbus等。

10.其他

SELinux中还有一些很少用到的客体，这里就不列举了。