grsecurity 总结

 GRSecurity 为ACL系统提供了内核模块的支持，另外，在用户空间，还需要有gradm这个工具。ACL是 Access Control List的简写，支持ACL的系统可以对系统及系统文件，系统资源进行细力度的访问控制。GRSecurity 还没有集成到linux内核中，如想使用需要自己下载相关内核补丁。目前grsecurity的补丁稳定版支持2.6.27.10的内核，测试版支持到了最新的2.6.31.5版内核。
给内核打补丁的步骤如下：
tar -jxf linux-<version>.tar.bz2
patch -p0 <grsecurity-<version>.patch
cd linux-<version>
make menuconfig
在Security options中就可以找到grsecurity的选项。

* 基本命令
启动grsecurity gradm -E
停止grsecurity gradm -D
切换到管理员角色 gradm -a admin ，注意，-a 参数只能用于从一个普通角色切换到管理员角色。

* 角色 subject object
要实现ACL（访问控制），需要有一个策略文件，grsecurity启动后，会根据该文件中的策略对系统进行访问控制。
该文件位于/etc/grsec/目录下，文件名为policy。

policy文件的语法格式如下：
role admin sA
subject / rvka
/ rwcdmlxi

role default
subject /
/ h
-CAP_ALL
connect disabled
bind disabled

role root uG
role_transitions admin
subject /
/ r
/opt rx
/home rwxcd
/mnt rw
/dev
/dev/grsec h
/dev/urandom r

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

+CAP_SYS_ADMIN
-PAX_MPROTECT

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

subject /sbin/klogd
+CAP_SYS_ADMIN

由例子可以看出，policy中有三个概念：
第一是角色role，如“role admin sA“，“role default ”，”role root uG“，表明有三个角色，分别是admin , default, root，至于角色与角色之间的关系，以及参数的含义，我们会在角色的定义这一节中讲到。
第二是subject，每个subject中首先定义了一个可执行程序（注意，一个subject中只定义一个可执行程序，要对多个可执行程序进行定义的话，就需要多个subject），或者更准确一点，定义了一个运行在系统中的进程。然后后面跟着一系列的object（第三个概念），用来规定当前这个进程的权限。每个角色定义的后面都可以跟一个或多个subject，例如角色default后面，就定义了一个subject，“subject /”，而角色root的后面就定义了多个subject，“subject /”，“subject /usr/X11R6/bin/XFree86”，“subject /usr/bin/ssh” ，“subject /sbin/klogd”。
第三是object，每个subject中都会有若干的object，表示每个进程都有若干个操作对象，这些操作对象一般来说都是一些目录，文件等等，用来规定当前这个subject中的进程对这些文件拥有哪些权限，例如：
subject /usr/bin/ssh
/etc/ssh/ssh_config r
表示/usr/bin/ssh这个进程对/etc/ssh/ssh_config这个文件有读权限（r）。更进一步讲，这个subject位于角色root后面，所以这两行策略的含义就是以root角色运行ssh时，ssh进程对/etc/ssh/ssh_config有读权限。该策略只定义在了root角色中，对于其他角色不起作用。

注意：在每一个角色中，都必须有一个subject /，表示一个缺省的ACL，如果没有这个缺省的ACL，grsecurity启动时会报错同时启动失败。当以一个角色登录系统后，如果要执行的可执行程序没有被某个subject定义，那么，该程序就会采用subject /中的缺省定义。例如root角色，没有对cat命令进行定义，所以以root角色执行cat命令时，ACL系统就会参照subject /中的定义来控制cat进程对文件的访问。

* 角色的定义
grsecurity的角色定义非常简单，只需要在policy中声明一下就可以了，语法为"role <role name> <parameter>"，如例子中的“role root uG”。
grsecurity中的角色分为用户角色，组角色，缺省角色（default），还有个管理员角色。定义不同角色需要有不同的参数。
定义用户角色，需要加参数“u”。定义组角色，需要家参数“g”，定义缺省角色可以什么参数都不加，定义管理员角色需要加"A"和“s”。注意，grsecurity的角色与用户是一对一的。假设有tester用户，属于test组，那么tester用户登录后，会先在
配置文件中匹配名为tester用户角色，如果没有，就会去匹配叫test的组角色，如果还没有，那么tester用户进入系统后的角色会是default（default角色在配置文件里面定义）。也就是说，tester用户登录后，不是tester用户角色，就是test组角色，要么就是defaul
t缺省角色，不可能进入其他policy中定义的角色。当然，登录之后可以切换角色，这需要配置相应的policy，参考角色切换一节的介绍。

定义角色的参数：
A – This role is an administrative role, thus it has special privilege normal
roles do not have. In particular, this role bypasses the additional ptrace
restrictions
N – Don’t require authentication for this role. To access the role, use
gradm -n <rolename>
s – This role is a special role, meaning it does not belong to a user or group,
and does not require an enforced secure policy base to be included in the
ruleset.
u – This role is a user role
g – This role is a group role
G – This role can use gradm to authenticate to the kernel A policy for gradm
will automatically be added to the role.
T – Enable TPE for this role
l – Enable learning for this role
P – Use PAM authentication for this role.

* subject和object的定义
关于policy中subject和object的定义，那是相当的复杂，最好的办法就是用gradm的学习模式自动生成策略。

* 角色的切换
在grsecurity系统中，角色的切换实际上就是用户的切换，通过su命令，由test01用户切换到test02用户，那么你的角色就由test01切换到了test02。当然，有两个前提，第一是你的policy是允许test01通过su命令进入test02的，否则根本
就且换不了用户，更别提角色的变化了，第二是你的policy中定义了test02这个角色，否则，系统将会去匹配test02所在组的组角色，如果组角色也没有定义，那么切换到test02后，你的角色就是default。

* grsecurity的学习模式
由于人工编写policy是非常复杂的，几乎是不可能完成的，所以gradm为我们提供了一个很强大很好用的学习模式，以使系统能够根据用户的日常操作，来学习哪些操作是被允许的，哪些文件是可读的，哪些文件是可写的等等。使用学习模式有一个前提，就
是作为用户，必须非常清楚哪些操作应该被允许，哪些操作不应该被允许。如果一个不应该被允许的操作，在学习模式开启的情况下却被执行了，那么gradm将会记录该操作，并把他列为允许执行之列。
学习模式有两种，分别是Process and role base learning（基于进程和角色的学习）和Full system learning（全系统学习）。下面分别介绍一下：

基于进程和角色的学习
该种学习模式可以指定某个角色或者某个角色中的特定进程进入学习模式，
例如：
role root uG
role_transitions admin
subject /
/ r
/opt rx
/home rwxcd
/mnt rw
subject /usr/bin/ls
/usr/share r

role test u
subject /
/ r
/opt rx
/home rwxcd
/mnt rw
subject /usr/bin/ls
/usr/share/test r

subject /usr/bin/cat
/etc/fstab rw

如果我们想让test角色学习，就在test角色定义处添加"l",如"role test ul"，这样的话，只要你进入这个角色，之后所有你执行的命令都会被学习模式记录下来。
如果只想让test角色中的ls进程学习，就在ls的subject处添加"l"，如"subject /usr/bin/ls l"。
设置完后，执行gradm -D, 确认grsecurity关闭，然后执
gradm -L /etc/grsec/learning.logs -E
进入学习模式。
我们以ls进程的学习为例，在学习模式下，切换到test角色（su test），然后执行设置了学习模式的命令"ls"，比如，想要"ls"对/etc/可读，那就执行"ls /etc/"，想要ls对/mnt可读，那就执行"ls /mnt"。当你需要做的所有操作都做了
至少4遍以后，就可以执行以下命令生成policy。
gradm -D #先要停止grsecurity
gradm -L /etc/grsec/learning.logs -O /etc/grsec/acl #生成acl文件
把acl文件中的内容复制粘贴到policy中对应的subject中。详细操作参看学习模式应用实例。

全系统学习
该学习模式下，系统将记录所有被policy文件deny的操作，并生成相应的policy，以保证这些被deny的操作在新的policy中不会被deny。
这种模式不需要修改配置文件，直接执行如下命令即可：
1）gradm -F -L /etc/grsec/learning.logs
2）执行你需要赋予权限的命令或操作至少4次
3）生成acl文件
gradm -F -L /etc/grsec/learning.logs -O /etc/grsec/acl
4）将acl中的内容复制粘贴到policy中。详细的复制粘贴方法参看学习模式应用实例。


用户切换后，角色也切换，角色的权限是不是继承的？
答：不会继承

* 在配置文件中写规则的注意事项
* 如果有多个配置文件，可以通过在/etc/grsec/polic中加入include </etc/grsec/acls>这种形式，使acls中的配置生效。