Selinux是什么?

在新的基于RHEL通常都自带了selinux，多数状况下咱们把selinux禁用了，事实上既然RHEL要集成它，必然有他的优势和长处，咱们经过下文来了解selinux，也许你会喜欢用上它。

英文原文来自www.RedHat.com
by Russell Coker
翻译：胡智江
主要内容
介绍：
SELinux概览：
SELinux深刻研究：
Fedora中策略的实现：
Fedora的缺省SELinux策略：
更多关于SELinux的资料：
关于做者和译者：

介绍：
当今世界，无处不在高速互联网链接、如备有无线接入点的咖啡馆和在网上处处传播的各类黑客工具使得出于对计算机安全的考虑成为老生常谈。出于解决安全问题，NSA在Linux社区的帮助下开发了一种访问控制体系，在这种访问控制体系的限制下，进程只能访问那些在他的任务中所须要文件。这种体系叫作 Security-Enhanced Linux或简化为SELinux。

SELinux概览：

SELinux是一种基于 域-类型 模型（domain-type）的强制访问控制（MAC）安全系统，它由NSA编写并设计成内核模块包含到内核中，相应的某些安全相关的应用也被打了SELinux的补丁，最后还有一个相应的安全策略。

众所周知，标准的UNIX安全模型是"任意的访问控制"DAC。就是说，任何程序对其资源享有彻底的控制权。假设某个程序打算把含有潜在重要信息的文件仍到/tmp目录下，那么在DAC状况下没人能阻止他！

而MAC状况下的安全策略彻底控制着对全部资源的访问。这是MAC和DAC本质的区别。

SELinux里实现的MAC容许程序在/tmp目录下创建文件，也容许这个文件按照UNIX权限字的要求对全世界可读，可是当UNIX许可检查应用后， SELinux许可检查还要进一步判断对资源的访问是否被许可。
换 句话说，尽管某些UNIX文件的权限被设定为0777可是你也许仍然会被禁止读，写和执行该UNIX文件。在只有DAC的状况下，用户能够查看或更改属于 他的任何文件。SELinux则能够限制每个进程对各类资源的访问，和访问的权级。就是说当一个程序在使用含有敏感数据时，这些数据会被禁止写入那些低 权级进程可读的文件中。

SELinux提供了比传统的UNIX权限更好的访问控制。

例如，管理员能够只容许一个应用程序添加记录到一个日志文件但不容许其重写或者删除该日志文件的内容。虽然ext2和ext3文件系统有一个 append-only标签（使用chattr设置）,可是这属性不区分某一个进程（不能在为一个访问 append-only的同时，又容许另外一个进程据有彻底可写的权利）；另外一方面，一个应用程序能够被容许在一个文件夹中创建文件和向其写入数据，但不能 删除文件：这种特性是没有SELinux的普通的Linux内核所不能作到的。还有，网络应用程序能够绑定到其须要的端口上（如BIND的53端口），但不能绑定其它端口。

域-类型模型意味着在安全域中运行着的每个进程和每个资源（通常文件、目录文件和套接字等）都有一个与之相联系的"类型"（type）。

在这基础之上创建了一系列规则，这些规则列出了某个域能够在每个类型上执行的全部动做。 域-类型模型的一个优势就是咱们能够对策略进行分析，从而判断出哪些信息有可能外溢。在标准的UNIX环境中，用户通常可使用ps命令来互相查看彼此的 进程列表，然而这也会为攻击者提供有价值的信息。甚至就算彻底阻止用户使用ps命令，信息仍是会意外的或故意的泄露，其实在一个给定的UNIX环境中，哪 些信息会发生泄露是没法判断的。

而在SELinux状况下，咱们会有不少工具用来分析SELinux策略并判断哪些信息泄露是可能的。举个例子，假若有两个应用程序被容许向一个日 志文件添加数据，且他们互相不能直接通讯。那么若是一个其中进程又得到了对该日志的读权限的话，那么一个单方通讯就有可能造成。

对访问/etc/shadow文件作访问限制是个很好的例子，经过该例子咱们能够看出策略分析的好处。
若是你装了Fedora Core 3,而且选择了严格的SElinux策略配置，那么将会有17个域被容许访问shadow_t(/etc/shadow的type)，其中有9个域据有写 权利。这17个域中有2个能够从用户域（user domain）进入，他们是/usr/bin/passwd和 /sbin/unix_chkpwd(一个为无特权应用程序提供密码检查的辅助程序，好比向锁屏程序就须要使用到unix_chkpwd)。这17个域中 的某些域是为一些不常见的应用程序准备的（如radius_t域就是为RADIUS服务器准备的），因此，也就是说，就算除去这个不经常使用的域，通常的系统 中还有16个可访问的域可以访问/etc/shadow呢！

值得注意的是，Fedora发型版的SELinux策略已经变得愈来愈灵活；将来版本的策略也许会使何以访问/etc/shadow的域超过17 个，这取决于可调节选项的实际配置。还要注意的是，17这个数字是基于严格的策略设定以后而得出的，实际上一个默认的安装会大于这个数字。

在一个没有SE的机器上，任何以root身份运行的进程均可以访问/etc/shadow文件。这意味着任何被"SETUID root"的二进制代码或以root身份运行的网络服务守护进程，它们所产生的任何安全问题都将会是灾难性的。

SELinux容许咱们限制这些守护进程只访问其所需：
BIND只能在53端口提供服务、DHCP服务器可使用原始套接字（raw network access）、DHCP客户端也可使用原始套接字并能够改变网络接口，可是它们谁都别想访问/etc/shadow,/home,/root等等这些重要的资源。
因此，在SElinux的状况下，若是BIND受到了危害，它最多也就是发送一些伪造的报文罢了。若是DHCPD受到了危害，最坏的可能就是你的ip地址分配被搞乱。这比root权力被远程滥用好多了！

你们很清楚，一个进程能够援引另外一个进程。

在这种状况下，拿DHCPD为例，DHCPD也许会尝试援引 /sbin/unix_chkpwd对密码进行强力攻击。（But even that potential vulnerability is closed）:SELinux可以提供"过渡"规则，这种规则能够用来判断各类域间过渡是否合法。有了"过渡"规则之后，由用户执行的屏幕保护程序能够 顺利过渡到/sbin/unix_chkpwd这样一个特权域，然而DHCPD就别想了。

上述这些限制功能可使你对系统的状态了如指掌。若是你发现你的DHCP服务器有BUG，那你只要简单的升级DHCP服务器到新版本而且肯定每个客户端都能正常得到IP地址就能够了。但是若是没有SE的话，你还要考虑你的新服务器是否已被黑客入侵并擦除了痕迹。

      SElinux 对不一样的域作了严格的隔离。我之前运行一个Debian系统有两年时间，在这期间我开放了他的root密码。最近两个月我在一个Fedora系统上作一样 的事情。但这两个系统已经抵抗住了不少次以root身份的攻击（见httphttp://www.coker.com.au/selinux /play.html）。（译者注：这里有一些做者对其playmachine的介绍被忽略了）

为了给RHEL4作代码测试，Fedora core 2已经尝试集成了SELinux，可是默认是关闭的。并且未来RHEL和Fedora Core的SE还会有很是大的差异的。咱们计划在RHEL中，将把SELinux的策略设置的比Fedora Core要严格，咱们相信这样作也符合用户的要求。将来的Fedora版本的SELinux策略将会愈来愈严格，但再严格也不会超过RHEL。

SELinux深刻研究：

SELinux的策略数据库控制着SELinux的方方面面。它能够判断一个程序可能会运行在哪一个域中，还能够说明某个域能够访问哪些资源。这种规 定被叫作规则，一个典型的策略每每拥有100,000条规则。别被这数字吓坏，咱们根本没必要去关心它，由于当咱们撰写策略时，咱们可使用高级宏，这些高 级宏的一行就能生成10,000条规则。除了宏之外，还有一些工具，使用他们能够分析这些生成的规则是否能达到你对安全的要求。其实再和设置每一个文件的 UNIX 权限位这样的工做比起来，这100,000个规则也是至关小的工做量了。

Fedora Core 2安全策略的目标是知足大多数用户无需改动就能够工做的要求，但也有一些普通的简单的选项能够调节策略，通常都是简简单单的一行选项。好比是否容许用户通 过dmesg阅读内核的日志，是否容许管理员（sysadm_r）直接经过SSH登录或登录图形会话，还有是否容许用户绑定TCP套接字。
那 100,000个左右的规则存储在一个大约2.6MB的文件中，当系统启动时随内核一块儿装入内存并占用一样大小（大约2.6MB）的内核空间。 Fedora Core 3默认的strict策略有着多余290,000条规则，占用7MB的内核空间。Fedora Core 3默认的target策略有大约5,000条规则，占用150K的内核空间。

目前，SELinux并无在内存使用方面进行优化；但如今对这些优化工做已经有了计划和一些下降内存使用的方法。若是你不打算使用某些守护进程， 你能够简单的将其对应的策略文件删除以便得到占用空间更少的策略。2003年，在Ottawa举办的一次Linux讨论会上，我提交过一篇文章，那是关于 我在把 SELinux移植到HP iPAQ PDA上所作的工做的文章(在http //archive.linuxsymposium.org/ols2003/Proceedings/能够得到)。

证实我可使SELinux（且选择 strict策略）很好的工做在一台只有 64 MBs的RAM 和32 MBs 存储空间的小平台上，而且我相信我还可使它运行在更小的平台上。针对Fedora Core2系统，咱们只把目光定位在目前最多见的硬件平台，从而得出了默认的策略配置。但那些使用老机器的用户们也许会但愿配置出最小限度的策略以便减小 内存使用和提升性能。

在使用了SELinux的系统中，每个进程的上下文都包含三个组成部分：一个ID（identity），一个角色（role）和一个域（domain）

ID是指这个进程的全部者，就是UNIX帐户，但前提是这个帐户必须被预先编译到SELinux策略中去使SELinux认识这个帐户，否则的话 SELinux默认地将那些未知的系统进程ID记为 system_u ，将那些未知的用户进程ID记为 user_u；角色用来判断某个处于此角色的ID能够进入哪些域，还用来防止某个处于此角色的ID进入其它不应进入的域。好比， user_r角色就不容许进入 sysadm_t （重要的系统管理域）。

换句话说就是，那些只有 user_u ID的进程只能扮演 user_r 这个角色，而 user_r 这个角色 永远不能被许可进入 sysadm_t 域。从而，那些只有 user_u 这个ID的人是别想进入 sysadm_t 域的。这些特点在缺省的Fedora Core2策略中并无彻底使用，当前咱们只是把努力花在制定守护进程上，而对用户域的策略限制的不多（targeted策略没有对用户登录作任何限 制）。

一个安全上下文能够像 identity:role:domain 这样一种描述符的方式简明的表现出来。

好比，典型的系统管理上下文能够表示成 root:sysadm_r:sysadm_t 。任何能够被访问的对象均可以这样来表示。值得注意的是，"域"其实也是和一个进程相对应的一个"类型"。因此当检查某个进程是否有权向另外一个进程发送信 号（好比为ps命令检阅/proc文件系统）时，接受信号的进程的"域"就会充当"域-类型"模型中的"类型"的角色，从而完成"域-类型"的规则检查。 即完成了进程间通讯权限的检查。因为对于文件尚未使用角色这个机制，因此目前每一个文件都被规定为object_r 角色（这个角色只是占个位置罢了，对策略没有任何影响）。

文件的ID就是文件建立者的ID。constraints 策略源文件中使用这个方式来判断一个访问是否有权改变某个文件的上下文描述符。除非被访问的文件的描述符中的ID字段和访问该文件的进程的全部者ID字段 相同，不管是改变前仍是改变后，不然进程无权改变一个文件的上下文描述符。

例如，一个拥有 rjc:user_r:user_t 描述符的进程能够将一个拥有 rjc:object_r:user_games_rw_t 描述符的文件的描述符改成rjc:object_r:user_games_ro_t ，可是它无权改变一个拥有 john:object_r:user_games_rw_t 描述符的文件的任何属性。

要想查看当前运行的进程的上下文描述符，可使用ps命令并加入 "-Z"选项，如例一："ps ax -Z的输出"：
  PID CONTEXT                                  COMMAND
1634 root:user_r:user_t                       -bash
1662 root:user_r:user_t                       ps ax -Z

Example 1. Example Output of ps ax -Z

要想查看目录下的文件的上下文描述符，可使用ls命令并加入 "-Z"选项，如例一："ls -Z的输出"：
drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
drwxr-xr-x  root     root     system_u:object_r:device_t       dev
drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
drwxr-xr-x  root     root     system_u:object_r:root_t         initrd
drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
drwx------  root     root     system_u:object_r:lost_found_t   lost+found
drwxr-xr-x  root     root     system_u:object_r:default_t      misc
drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
?---------  ?        ?                                         oracle
dr-xr-xr-x  root     root                                      proc
drwxr-x---  root     root     system_u:object_r:user_home_dir_t root
drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
drwxr-xr-x  root     root                                      selinux
drwxr-xr-x  root     root     system_u:object_r:default_t      srv
drwxr-xr-x  root     root                                      sys
drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
drwxr-xr-x  root     root     system_u:object_r:var_t          var

Example 2. Example Output of ls -Z

值得注意的是：对于那些没有指定上下文的文件（通常是指那些不支持rwx标签的文件系统，如/sys、/proc、/selinux），ls命令就 不会显示其上下文。对于不能用stat命令查看当前状态的那些文件系统。ls命令返回"?---------",其全部者和全部组也被标记为"？"，一样 的，他的上下文也不会显示。
      如例三所示，id命令将返回当前shell的上下文
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:user_r:user_t
Example 3. Example Output of the id Command

      若是你的SELinux系统使用了strict 策略，你会发现应用程序作一些不正常的事情是很容易发生的。你常常会发现某些程序中会有些bug，这些bug使程序作那些你的SELinux策略不容许其作的其它事情。
SELinux 要求进程的上下文只有在被执行的"那一刻"才容许改变。新进程的域和角色信息能够从exec系统函数的上下文和文件类型中自动得到。进程也能够在执行 exec以前被指明上下文。这些过程天然受SELinux策略的控制，由于ID，角色和域都受SELinux策略的控制。

Fedora中策略的实现：

从 Fedora Core 3 开始，SELinux的策略数据存储于/etc/security/selinux/X/src/policy/目录下（X指你选则的策略，能够是 "strict" 或者 "targeted"）。在这个目录中，你可使用"make load"来编译并装在策略。也就是用那个命令将策略编译成二进制格式并装在到内核中，并当即生效。除了装如内核，该命令还将策略的二进制格式存储到 /etc/selinux/X/policy/policy.YY文件中，这里X指你选则的策略，能够是"strict" 或者 "targeted"，YY是策略的版本号（Fedora Core 3支持最新的版本是18）。这是为了在系统开机的第一时间，init能够迅速装载策略到内核。/etc/selinux/config这个配置文件用来告 诉init那些策略须要装载。

当你启动一个SELinux时，init所作的第一件事就是挂载/proc文件系统，并判断SELinux是否被激活。init经过 selinuxfs文件系统类型来判断内核中是否有SELinux，若是内核中没有SELinux或者内核参数中 selinux=0 这一项，那么系统就会以一种叫作 non-SE的状态被继续引导启动。若是发现了SELinux，那么/selinux虚拟文件系统将被建立，而后，init经过 /selinux/policyvers来检查内核所支持的SELinux版本。最后，相应的策略数据 /etc/selinux/X/policy/policy.YY就会被装在到内核中去了。

当策略被装载完以后，全部正在运行着的进程（指的就是init和内核的全部线程）都将被指定 system_u:system_r:kernel_t 这样一种上下文（内核线程其实不管在什么时间被建立，其上下文都是system_u:system_r:kernel_t ）。当init装载完策略以后，它还要从新执行本身。策略中有一个规则叫domain_auto_trans(kernel_t, init_exec_t, init_t)。他的意思就是当 kernel_t 域执行了一个据有 init_exec_t 类型的可执行文件（如/sbin/init）,那么该执行文件对应的进程的域就会自动过渡到 init_t 域（这是/sbin/init正确的所在域）。当这些都完成以后，init就继续完成那些一般的任务来完成机器的启动。内核线程自始至终都以 kernel_t 这个类型运行。

文件和目录的上下文存储于扩展属性当中 (XATTRs)。更多关于XATTRs的信息请参考attr(5), getfattr(1) 和 setfattr(1)的manpage。

简单的说，一个XATTR就是硬盘上某个文件的全部权，它由文件名和其它一些信息组成。对于每一个 persistent 文件系统来讲，它的每一个文件或目录的SELinux上下文就存储在 security.selinux属性当中。虽然/proc文件系统不是persistent 文件系统，但SELinux仍是在幕后为其文件和目录作了上下文标记，只是不能用getxattr得到罢了。和它对比，devpts文件系统（应用于 /dev/pts Unix98伪终端）中各个文件（各个伪终端）的上下文是能够经过getxattr来得到的，并能够经过 setxattr 来更改每一个设备的上下文（以便sshd等相似程序能够更改tty设备的上下文）。对于那些拥有固定存储的文件系统(ext2, ext3, Reiserfs, XFS, vfat, 等等) 有两种选择用于设定文件上下文：
第一种：文件系统的类型就规定了其内部每个文件英据有统一的上下文；
第二种：使用 XATTRs 为每一个文件标记不一样上下文。例如，在iso9660（CD-ROM）文件系统中的每个文件的上下文都是system_u:object_r:iso9660_t ，这被称作 genfs标记。

Ext2, ext3 和XFS支持 XATTRs 并且 Fedora 系统也支持安全标记名字空间，因此Fedora默认使用 XATTRs 来标记文件的上下文，但这也是可选方法之一。由于 直到 Reiser4发布以前 ，Hans Reiser对 支持XATTR没多大兴趣，因此Fedora的 ReiserFS 文件系统不能很好的支持SELinux标记操做。也就是说，使用 ReiserFS 文件系统做为SELinux的根文件系统是不可能的事情。

XFS有一个与XATTRs相关的重要的问题：若是XATTRs不能被装入超级块（inode），那么它们就会被装入数据块，每个超级块就要使用 一个数据块用来装 SELinux XATTR 。创建XFS时，mkfs.xfs在默认状况下建立的数据块大小为4096,超级块大小为256（要是用于安装 SELinux XATTR ，大约缺乏30字节）。这就是说，默认的XFS文件系统中，每个超级块要占用4096字节用来装载 SELinux XATTR ，这对于磁盘空间来讲是严重的浪费！当你使用"-i size=512"选项建立一个XFS文件系统时，超级块的大小就变成了512字节，这样就能够将SELinux XATTR 装入超级块，即节省了空间，又提升的性能。512字节的超级块也有可能给其它操做带来好处。因此，若是你使用XFS而且打算未来使用 SELinux 的话，将超级块的大小规定为512字节确定是个好主意。

若是你使用的是较新的内核（如最新的Fedora内核或标准2.6.8.1内核）而且使用最新的mount工具，那么当你挂载一个文件系统时，有一 个选项能够用来为整个文件系统指定上下文标签。好比你要挂载的文件系统是一个邮件池（mail spool），你可使用"-o context=system_u:object_r:mail_spool_t"选项来挂载他，这样会将其内部的所有文件的上下文标记为 system_u:object_r:mail_spool_t。若是你的这个邮件池很大，并且仍是XFS文件系统，这个方法还能够避免上一段所讨论的 inode大小的问题。甚至对于ext3那样的对XATTRs 开销较小的文件系统来讲，使用context=选项挂载文件系统也会进一步减小开销，也能够避免为已经创建的文件系统从新设置 SElinux上下文（若是文件系统中文件较多的话，会浪费很长的时间）。

Fedora的缺省SELinux策略：

在Fedora Core 3系统中，缺省的策略是"targeted "策略。对于此种选择人们议论纷纷，问题在于咱们但愿能使尽量多得人使用SELinux。若是人们以为这玩意太可怕而且妨碍了人们作他们想作的事，那么 人们会把它关掉。因此咱们在这个时候宁愿为大多数人提供适量的保护策略，也不会为了少部分人而提供严格的保护策略。缺省的Fedora Core 3安装会激活 SELinux 并使用"targeted "策略，你也能够经过运行 system-config-securitylevel 这个程序将策略改成更加严格的 "strict "策略。

若是你安装了策略的源文件包，那么策略的源文件就在/etc/selinux/X/src/policy/目录里面（X指你选则的策略，能够是 "strict" 或者 "targeted"）在这个目录下有一个叫做domains/program/的子目录，里面为每个守护进程对应了一个.te文件。你能够删去那些你 不使用也不打算使用的守护进程所对应的.te文件，从而减小内核内存空间的使用，并提升性能。好比，你的系统没有BIND服务，你彻底能够删掉 named.te 文件。而后若是你使用"make load"命令从新装载策略到内核的话，内核对内存的使用量就会减小。然而也要当心，若是你误删了其它文件，那么你的系统将不能正常启动进入 enforcing模式。因此目前，这种调节最好仍是由内行来作。

刚开始接触SElinux的你，要注意一个内核参数，它用来决定你系统的内核运行于 强制（enforcing ）模式仍是自由（permissive）模式，那就是"enforcing"参数。在自由模式下SELinux只是记录他该作什么，而事实上并不作任何动 做。在强制模式下SElinux会来真格的。若是你的策略有错误，在强制模式下系统可能会阻止你登录！因此正常状况下你应改在启动时传 enforcing=1 给内核，当你的SELinux策略有问题时，你能够临时传enforcing=0给内核来查错。在/etc/selinux/config这个init的 配置文件中相应的有一个选项，经过设置它，也可使系统进入自由模式。

若是你打算停止使用SELinux，你可使用 selinux=0 这个内核参数。这会关闭SELinux的所有功能，就好像你的内核并无把SElinux机制编译进去同样。因此当系统出了问题时，好比系统崩溃，有些人 就用此方法进行理事的恢复工做，可是我并不同意这种作法。当你临时使用 selinux=0 进入系统后，你所创建的任何文件将不会拥有SELinux上下文标记。这就意味着，若是你替换了诸如/etc/passwd 或/etc/shadow等重要文件，那么下一次进入SELinux时，系统就不会正常的工做。这不是严重的问题，当你从CD引导时，作系统恢复时，或使 用一个不支持 XATTRs备份软件恢复系统时，一样的问题也会发生。这个问题虽然能够经过为受到影响的文件系统从新标记上下文来解决，可是使用 enforcing=0 来代替 selinux=0 不是更好吗？
你能够编辑/etc/selinux/config来临时关闭SELinux。

Fedora Core 2的释放是SELinux一次重要的发展。他是第一套提供对SELinux完整支持的主流Linux发行版本。Fedora Core 3 也是一个重要的里程碑，由于他是第一套将SELinux做为默认安装选项的Linux发行版本。
Red Hat Enterprise Linux 4 见会跟随 Fedora Core 的开发步伐，其对SELinux的支持也会获得进一步的发展。当 RHEL 4 发布时，她将会从 Fedora Core 系统和在Fedora 上学习SELinux的用户那里得到很是大的益处。

你能够在 irc.freenode.net的 IRC服务器上的#fedora-selinux频道找到对SELinux的支持。还有 Fedora SELinux邮件列表 http://www.redhat.com/mailman/listinfo/fedora-selinux-list。我常常挂在#fedora-selinux上面，并也订阅了邮件列表，我指望着在那里回答您提出的任何问题。

更多关于SELinux的资料：

NSA site for Security-Enhanced Linux:http://www.nsa.gov/selinux/
Fedora Core SELinux FAQ:http://people.redhat.com/kwade/fedora-docs/selinux-faq/
IRC channel for SELinux in Fedora Core: irc.freenode.net, #fedora-selinux
Mailing list for SELinux in Fedora Core:http://www.redhat.com/mailman/listinfo/fedora-selinux-list
SELinux play machine:http://www.coker.com.au/selinux/play.html

关于做者和译者：

Russell Coker 从2003年就为RedHat的 SELinux 工程工做。在那以前他是一个独立的顾问并在闲暇时间研究SELinux。他第一次了解SELinux 是在 2001 年Ottawa Linux 讨论会上，当时 NSA 的Pete Loscocco 针对SELinux作了一个演讲。在2002 的OLS 上他介绍了他如何将SELinux移植到Debian Linux上. 做为移植工做的一部分, 他还撰写了用于支持全部他使用的程序的策略, 这些策略后来成为了SELinux策略的主要来源. 在OLS2003 和 Linux Kongress 2002上他也发表了文章。

译者：胡智江，就读于江苏大学通讯工程系。从1999年开始使用Linux，2003年经过了RHCT认证。对Linux系统和嵌入式系统都很感兴趣。翻译这篇文章主要是为了学习SELinux，而后和你们分享成果。但愿你们对译文的错误做出批评和指正。

来源：http://blog.csdn.net/flaght/article/details/2973910