最后make , make load
[root@python policy]# pwd
/etc/selinux/refpolicy/src/policy
[root@python policy]# make;make load
正常终了后，我们能够用 semodule命令来确认 azureus.pp下载下去了没有。
[root@python policy]# semodule -l |grep azureus
azureus 1.0.0
看样子是没有问题。好了我们再看看 /home/fu/azureus/azureus的security context，我们刚才在azureus.fc里是期望他是 user_u:object_r:azureus_exec_t ，可是他这个时候还是继承了默认的 user_u:object_r:user_home_t ， 假如不是我们期望的文档标签的话，domain是无法从user_t迁移到azureus_t的，因为relabel的话，会对整个文档系统进行重新设标签，很花时间，所以我们用在上面介绍过文档标签更改的命令chcon命令来改标签。
[root@python azureus]# chcon -t azureus_exec_t azureus
再看看这次的新标签，果然如我们期望的，变成azureus_exec_t了。
[root@python policy]# ls -lZ /home/fu/azureus/
-rwxr-xr-x fu fu user_u:object_r:azureus_exec_t azureus
-rw-r--r-- fu fu user_u:object_r:user_home_t Azureus2.jar
接下来退出ROOT用户，以用户fu登录，运行azureus命令。
[root@python azureus]# ps -efZ|grep azureus
user_u:user_r:azureus_t fu 8703 8647 0 23:23 pts/1 00:00:00 /bin/bash ./azureus
user_u:user_r:azureus_t fu 8717 8703 4 23:24 pts/1 00:01:29 java -Djava.ext.dirs=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext -Xms16m -Xmx128m -cp /home/fu/azureus/Azureus2.jar:/home/fu/azureus/swt.jar -Djava.library.path=/home/fu/azureus -Dazureus.install.path=/home/fu/azureus org.gudy.azureus2.ui.swt.Main
user_u:user_r:user_t root 9347 1956 0 23:59 pts/2 00:00:00 grep azureus
高兴吧！ 成功了。
在这里我只是演示如何让domain迁移，至于azureus的严格的access vector的配置我都忽略了。
5.3 给自己增加个专用的ROLE
在这里我们要增加一个叫madia的ROLE，在追加时要对一些文档进行修改。
5.3.1 /etc/selinux/refpolicy/src/policy/policy/modules/kernel下的文档修改
1) kernel.te
[root@python kernel]# vi kernel.te
在role user_r 的下面加上一行
role madia_r;
2) domain.te
[root@python kernel]# vi domain.te
在 role user_r types domain; 的下面加上一行
role madia_r type domain;
5.3.2 /etc/selinux/refpolicy/src/policy/policy/modules/system下的文档修改
[root@python system]# vi userdomain.te
在第5行追加madia_r,如下所示：
role sysadm_r, staff_r, user_r,madia_r;
在unpriv_user_template(user)下面加上下面的一行。
unpriv_user_template(madia)
5.3.3 /etc/selinux/refpolicy/src/policy/policy下的文档修改
1）user
users和策略1.X里的users差不多。定义用户能利用的ROLE。
[root@python policy]# vi users
gen_user(madia, madia, madia_r, s0, s0)
2）rolemap
[root@python policy]# vi rolemap
在user_r user user_t下面加上一行
madia_r madia madia_t
5.3.4 重新make 策略
[root@python policy]# make load
5.3.5 /etc/selinux/refpolicy/seusers 文档的修改
Seusers是系统一般用户和SELinux的用户映射。
[root@python refpolicy]# vi seusers
madia:madia
5.3.6 /etc/selinux/refpolicy/contexts下的文档修改
1)default_type
决定用户登录时的默认ROLE。
[root@python refpolicy]# vi contexts/default_type
madia_r:madia_t
2）default_contexts
决定用户登录时的默认security context
[root@python refpolicy]# vi contexts/default_contexts
system_r:local_login_t madia_r:madia_t staff_r:staff_t user_r:user_t sysadm_r:sysadm_t
5.3.7 以madia用户重新登录
最后以用户madia登录，查看是不是 进入madia_t了。
[madia@python ~]$ id
uid=501(madia) gid=501(madia) groups=501(madia) context=madia:madia_r:madia_t
以上我们能够看出，madia用户确实是进入了madia_t 运行了。
我们在以上的操作中，实际上更有修改遗漏的地方，每当重新make的时候，seusers都会回到原来的设定，有兴趣的朋友能够自己找出哪里还需要修改。
6.最后
我们现在主要还是targeted策略，因为我们的服务器，基本上也就跑apache,postgresql,tomcat,bind,postfix这几个服务。Targeted能够保护他。我们的目标是将一些影响比较小的，服务比较单一的服务器移植到能运行strict策略的服务器上。当然，即使我们用SELinux，对于系统的安全也不能掉以轻心，认为有了SELinux就100％安全。
比如targeted里有unconfined_t，任何在这个domain里运行的都是不被保护的。更有，系统管理员对TE的配置错误造成不能很好的保护，还内核的漏洞，Dos攻击等，SELinux也是无能为力的。
除了SELinux外，更有LIDS ，TOMOYO LINUX，AppArmor等安全操作系统。大家对LIDS和AppArmor有可能比较熟悉，TOMOYO是 日本NTT数据公司研发的。也许有朋友在选择的时候不知道该用那个好。
安全级别高易用性高
SELINUX >> TOMOYO >> LIDS >> AppArmor
个人觉得，SELinux虽然配置起来麻烦了点，但是能达到军事安全级别，要玩的就话，还是SELinux有魅力。
现在也有人在研发策略的GUI编辑器，如SEEDIT，是日本日立软件工程公司的一个叫中村雄一为中央研发的。有了这些GUI的工具，将来定制策略会越来越容易的。
本文来自ChinaUnix博客，假如查看原文请点：http://blog.chinaunix.net/u2/62871/showart_505417.html
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
