如果我们增加一条-ctx语句到我们的setkey文件中，如：

[root@scarecrow ~]# cat dev/ipsec/setkey.scarecrow.test spdflush; flush; spdadd 192.168.147.130 192.168.147.132 any -ctx 1 1 "system_u:object_r:default_t:s0" -P in ipsec esp/transport//require; spdadd 192.168.147.132 192.168.147.130 any -ctx 1 1 "system_u:object_r:default_t:s0" -P out ipsec esp/transport//require;

你可以使用setkey –DP在每一台机器上查看SPD条目，注意条目的上下文字段。

在其他机器上重复设置setkey文件，注意你不能在标签中使用默认的default_t，它是一个展示发生什么事情的例子，它不是用来创建SA的标签，它将用于一个规则来查看哪个SPD条目与一个域匹配，这将在后面解释。

运行setkey –f收到一个错误的结果：

[root@scarecrow ~]# setkey -f dev/ipsec/setkey.scarecrow.test The result of line 8: Permission denied. The result of line 14: Permission denied.

查看拒绝信息：

[root@scarecrow ~]# tail /var/log/audit/audit.log | grep AVC type=AVC msg=audit(1179150979.762:33): avc: denied { setcontext } for pid= 21632 comm="setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=association type=AVC msg= audit(1179150979.895:34): avc: denied { setcontext } for pid=21632 comm= "setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext= system_u:object_r:default_t:s0 tclass=association

非常好，它告诉我们可以在哪个IPSec SPD上设置标签了，现在在两台机器上设置许可模式并再次运行setkey，将会成功。

[root@poisonivy ~]# ./client 192.168.147.132 Received: Hello, root:system_r:unconfined_t:SystemLow-SystemHigh from root: system_r:unconfined_t:-SystemHigh

你可以使用setkey –D来查看新创建的SA，注意每个条目中上下文的字段。希望下面这张图能传达SA是如何标记的，注意连接的每一边都有2个SA，一个标记入站一个标记出站，出站SA在每个系统上总是本地域，入站SA在每个系统上总是远程域。

我很感谢Chris Ashworth制作这张图，它比我想象的更简单易懂。

这就论证了当服务端调用getpeercon()时它看到了root:system_r:unconfined_t:SystemLow-SystemHigh，客户端看到了root:system_r:unconfined_t:-SystemHigh，使用runcon在不同上下文中运行客户端可以看到更多的不同之处：

[root@poisonivy ~]# runcon -t httpd_t ./client 192.168.147.132 Received: Hello, root:system_r:httpd_t:SystemLow-SystemHigh from root: system_r:unconfined_t:-SystemHigh

现在你可以看到服务端调用getpeercon()时的标签是httpd_t，因此现在我们明白了你如何在一个连接的另一端标识进程的上下文了，但是策略如何处理呢？

清除dmesg的内容，设置setenforce 1; setenforce 0，重新开始进程，首先运行setkey，然后运行audit2allow –d，将会显示：allow unconfined_t default_t:association setcontext;

这意味着unconfined_t尝试和default_t一起设置上下文，因为我们在SPD条目中使用了default_t，所以它是预期的结果，运行dmesg –c清除内核缓冲区，并尝试运行服务端和客户端（使用runcon）：

移除不相干的规则，在客户端我们可以看到类似下面这样的规则：

allow httpd_t default_t:association polmatch;

这条规则意味着客户端（作为httpd_t运行）企图再次匹配我们之前增加的SPD条目，这个非常有用，因为你可以使用SELinux策略来强制哪个SPD条目与一个域匹配，例如：你想让一些域使用高强度的加密，而另外一些域使用更快速的，低强度的加密，那么你就可以指定哪个SPD类型与哪个域进行匹配。

allow httpd_t self:association sendto;

这条规则指出httpd_t发送数据到标记为httpd_t的团体，意味着它发送到为它创建的团体，注意目前你还不能控制哪个域发送到另一端。

allow httpd_t unconfined_t:association recvfrom;

这是最有效的控制，它告诉我们允许httpd_t接收来自一个标记为unconfined_t的团体的消息，标记为unconfined_t的团体运行在unconfined_t下，这就允许你使用策略来决定其他机器使用哪个域向你本地机器发送数据。

allow unconfined_t default_t:association polmatch;

这是在这台机器上远程域（服务端）再次匹配入站SPD条目，注意有2条SPD条目被增加进来了，一个为出站通讯一个为入站通讯，两个域分别在本地机器上（为出站）和远程机器上（为入站）匹配SPD条目。

可能会在服务端收到类似的拒绝信息，仅仅与之前的颠倒过来了，我不想重提了。使用这个技术你要做到心中有数，假设你控制了两个策略（源和目标），你非常肯定哪个域可以域机器进行通讯，哪个是跨过机器的，与SELinux IPC控制类似，但它是跨网络的。

例如：一个应用了这个技术的应用程序在雇员工作站上有一个内部和外部的浏览器，内部浏览器运行在一个域上，它允许访问公司内部包含了机密的客户信息的web应用服务器，外部浏览器可以访问internet，这就可以减少流氓internet内容泄露你内部数据的风险，这中分离的方式如果没有SELinux高级网络控制支持实现起来将非常困难（甚至是不可能实现的）。
在SELinux网络环境下同时使用IPSec和netfilter技术你将获得惊人的安全，为了更安全，你需要调式更多的信息。

值得特别感谢的是那些为这个技术努力工作的人们，将来他们会使网络架构更安全，这些人包括：James Morris, Venkat Yekkirala, Joy Latten, Paul Moore (实现了NetLabel)等

上一页  [1] [2] [3] [4] 下一页