自定 SELinux 策略Word格式.docx
《自定 SELinux 策略Word格式.docx》由会员分享，可在线阅读，更多相关《自定 SELinux 策略Word格式.docx（10页珍藏版）》请在冰点文库上搜索。
进程可以更改安全性属性：
每位用户的邮件文件应该只供该用户读入，但邮件客户端软件有能力将它们改为谁都可读入。
进程继承用户的权限：
假若Firefox被人占用，它可以阅读用户的私人ssh金钥，尽管它没有理由如此做。
基本上现时只在两个权限级别，root及普通用户，而当中不能简易地实施最小权限的理念。
很多由root引导1的进程在后期会撇除它们的权限并以受限制的用户身份来运行，有些则会在chroot的情况下执行，但这些安全措施都是酌情的。
1.2.解决方案
SELinux遵从最小权限的理念。
在缺省情况下一切均被拒绝，接着要为系统的每部份（一项服务、程序、用户）写一个策略来允许它访问所需的功能。
当一项服务、程序或用户尝试访问或修改一个它不须用的文件或资源时，它的请求会遭拒绝，而这个行动会被记录下来。
由于SELinux是在内核中实践的，因此应用程序无须被特别编写或重写便可以采用SELinux。
假若SELinux拦阻了一个行动，对该应用程序来说它只会是个正常的「拒绝访问」类错误。
SELinux拥有三个基本的操作模式，当中Enforcing是缺省的模式。
*
Enforcing：
这个缺省模式会在系统上启用并实施SELinux的安全性策略，拒绝访问及记录行动
Permissive：
在Permissive模式下，SELinux会被启用但不会实施安全性策略，而只会发出警告及记录行动。
Permissive模式在排除SELinux的问题时很有用
Disabled：
SELinux已被停用
SELinux的模式可以通过Adminstration选单里的SELinux图像管理界面、或者在命令行执行system-config-selinux来查看及更改（SELinux图像管理界面是policycoreutils-gui组件的一部份，缺省是不会被安装的）。
较喜欢命令行的用户可使用sestatus这个指令来查看现时的SELinux状况：
#sestatus
SELinuxstatus:
enabled
SELinuxfsmount:
/selinux
Currentmode:
enforcing
Modefromconfigfile:
enforcing
Policyversion:
21
Policyfromconfigfile:
targeted
setenforce这个指令可以即时切换Enforcing及Permissive这两个模式，但请注意这些改动在系统重新开机时不会被保留。
要令改动过渡系统开机，请在/etc/selinux/config内修改SELINUX=这一行为enforcing、permissive或disabled。
例如SELINUX=permissive。
注：
当你由Diabled切换至Permissive或Enforcing模式时，我们强烈推荐你重新引导系统并重新标签文件系统。
较早前我们提及SELinux遵从最小权限这个理念；
在缺省情况下一切均被拒绝，而系统的每部份有一个策略来允许它访问所需的功能。
这个描述用来形容严格型策略最为贴切。
不过，这类策略必须适用于企业级Linux可能会应用到的各个环境下，因此编写方面是困难的。
后果可能是SELinux会为系统管理员及用户产生很多问题，而系统管理员只会停用SELinux而不解决这些问题，最后还是违背了原先的目的。
兴幸地，SELinux允许调配不同类型的策略。
CentOS4及5内的缺省策略是针对型策略，专门「针对」和规限主要的系统进程。
CentOS4只定义了15个目标（包括http、named、dhcpd、mysqld），但在CentOS5这个数字升至超过200个目标。
系统内其它一切都在不受规限的本地下运行并且不受SELinux影响。
这里的目标是要令每个被安装的进程在开机时都缺省在一个受规限的本地下运行。
针对型策略在设计时尽量保护最多的主要进程而不会对用户的经验产生不利影响，所以多数用户甚至乎不应察觉SELinux正在运行中。
4.SELinux访问控制
SELinux拥有三种访问控制方法：
强制类型（TE）：
TE是针对型策略所采用的主要访问控制机制
基于角色的访问控制（RBAC）：
它以SELinux用户（未必等同Linux用户）为基础，但缺省的针对型策略并未采用它
多层保障（MLS）：
未被采用，而且经常隐藏在缺省的针对型策略内。
所有进程及文件都拥有一个SELinux的安全性脉络。
让我们查看Apache的主页，index.html的SELinux安全性脉络来看看它们如何运作：
$ls-Z/var/www/html/index.html-rw-r--r--
philphilsystem_u:
object_r:
httpd_sys_content_t/var/www/html/index.html
-Z这个标旗在多数工具内都可用来显示SELinux安全性脉络（例如：
ls-Z、psaxZ等）。
除了标准的文件权限及拥有权，我们更可以看到SELinux脉络栏：
system_u:
httpd_sys_content_t。
这是建基于「用户：
角色：
类型：
多层保障」。
在上述例子里，「用户：
类型」栏都有显示，而「多层保障」是隐藏的。
在缺省的针对型策略里，类型是用来实施「强制类型」的重要字段，在这里它是httpd_sys_content_t。
现在让我们看看Apache网页服务器这个进程，httpd的SELinux安全性脉络：
$psaxZ|grephttpd
system_r:
httpd_t
3234?
Ss
0:
00/usr/sbin/httpd
从类型栏我们看出Apache在httpd_t这个类型本地内运行。
最后，让我们看看位于我们的主目录内的一个文件的安全性脉络：
$ls-Z/home/phil/myfile.txt
-rw-r--r--
philphiluser_u:
user_home_t
/home/phil/myfile.txt
它的类型是user_home_t，这是位于每个户主目录内的文件的缺省类型。
唯有相似的类型才可互相访问，因此以httpd_t运行的Apache可以读入拥有httpd_sys_content_t类型的/var/www/html/index.html。
由于Apache在httpd_t这个本地内运行，它不能访问/home/phil/myfile.txt，纵使这个文件可供任何人读入，因为它的SELinux安全性脉络并不是httpd_t类型。
倘若Apache被人占用，它不能引导任何在httpd_t本地以外的进程（这样可防止权限升级），或者访问任何位于httpd_t相关本地以外的文件。
你终有一天会被SELinux阻止你访问所需的东西，而且要解决这个问题。
SELinux拒绝某个文件、进程或资源被访问的基要原因有数个：
*一个被错误标签的文件
*一个进程在错误的SELinux安全性脉络下运行
*策略出错。
某个进程要访问一个在编写策略时意料不到的文件，并产生错误信息
*一个入侵的企图。
头三个情况我们可以处理，而第四个正正是预期的表现。
日志档是排除任何疑难的关键，而SELinux亦不例外。
SELinux缺省会通过Linux审计系统（auditd）将日志写在/var/log/audit/audit.log内，而这项务服缺省为启用的。
假若auditd并未运行，信息将会被写进/var/log/messages。
SELinux的日志都被标签有AVC这个关键字，方便它们从其它信息中过滤出来。
由CentOS5起，你可以用SELinux排除疑难工具协助你分析日志档，将它们转换为供人阅读的格式。
这个工具包含一个以可读格式显示信息及解决方案的图像界面、一个桌面通报图示、与及一个长驻进程（setroubleshootd），它负责查阅新的SELinuxAVC警告并传送至通报图示（不运行X服务器的话可设置以电邮通报）。
SELinux排除疑难工具是由setroubleshoot组件所提供，并缺省会被安装。
这个工具可以从「系统」选单或命令行引导：
sealert-b（图形）
不运行X服务器的人可以通过命令行产生供人阅读的报告：
sealert-a/var/log/audit/audit.log>
/path/to/mylogfile.txt
5.1.重新标签文件
chcon这个指令可以用来更改一个或多个文件与目录的SELinux安全性脉络，正如chown或chmod可以用来更改一个文件的拥有者或标准权限。
让我们看一些例子。
就以Apache为例，假设你想修改DocumentRoot以另一个位置来伺服网页，替换缺省的/var/www/html目录。
譬如说我们在/html创建了一个目录（又或者挂载点），然后在那里创建我们的index.html档：
#mkdir/html
#touch/html/index.html
#ls-Z/html/index.html
rootrootuser_u:
default_t
/html/index.html
#ls-Z|grephtml
drwxr-xr-x
html
我们可以见到/html这个目录以及/html/index.html这个文件都拥有缺省的default_t安全性脉络类型。
如果我们打开浏览器并尝试查看该页，SELinux将会拒绝它们被访问并记录错误，因为该目录与文件拥有不正确的安全性脉络。
我们须要设置供Apache使用的httpd_sys_content_t正确安全性脉络：
#chcon-v--type=httpd_sys_content_t/html
contextof/htmlchangedtouser_u:
httpd_sys_content_t
#chcon-v--type=httpd_sys_content_t/html/index.html
contextof/html/index.htmlchangedtouser_u:
httpd_sys_content_t
/html/index.html
html
我们同样也可以利用-R这个回递标旗同时将它们的脉络设置：
#chcon-Rv--type=httpd_sys_content_t/html
更改用户：
chcon-v-R-uuser_u-tuser_home_dir_t/var/www/html
以这个方式更改安全性脉络在系统重新开机后仍会获保留，除非整个文件系统被重新标签（见下文）。
要作出永久性、可以过渡文件系统重新标签的安全性脉络改动，我们可以采用SELinux管理工具，或者在命令行执行semanage这个指令：
semanagefcontext-a-thttpd_sys_content_t"
/html（/.*）?
"
如此便会将/html以下的一切加入httpd_sys_content_t这个文件脉络类型。
5.2.撤消缺省的安全性脉络
restorecon这个指令可以用来撤消为文件缺省的安全性脉络。
让我们再次以Apache作为样例。
设假有位用户在他的主目录内编辑了一个index.html档并将该文件迁移（mv）至DocumentRoot的/var/www/html内。
纵使复制（cp）这个指令普遍会沿用目标目录或文件的安全性脉络，迁移（mv）指令则会保留源文件的安全性脉络。
我们可以利用chcon这个指令来更改问题文件的安全性脉络，但由于这些文件已经位于Apache缺省的DocumentRoot（/var/www/html）内，我们只须撤消这个目录或文件的安全性脉络便成了。
要单单撤消index.html档的脉络，我们可以利用：
#restorecon–v–F/var/www/html/index.html
如果要以回递的方式撤消整个目录的缺省安全性脉络：
#restorecon–Rv–F/var/www/html
除此之外，如果我们只想检查/var/www/html目录内有哪些文件的安全性脉络需要被撤消，我们在采用restorecon时可以应用-n这个标旗来防止重新标签的行动：
#restorecon-Rv–F-n/var/www/html
5.3.重新标签整个文件系统
有时我们也许会需要将整个文件系统重新标签，虽然这是在启用已停用的SELinux时，或在SELinux策略由缺省的针对型改为严格型时才有真正需要。
要在重新开机后自动将整个文件系统重新标签，请执行：
#touch/.autorelabel
#reboot
假若一个系统在升级至CentOS-5.2时停用了SELinux，然后SELinux被启用，重新标签整个文件系统时或许会失败。
如果以上的步骤不能正确地将整个文件系统重新标签，请尝试先执行genhomedircon这个指令：
#genhomedircon
5.4.允许访问某个端口
我们或许会想容让Apache连结至某个非标准的端口并聆听对内的连接。
SELinux的策略缺省只允许每个服务访问被公认与该服务有关的端口。
如果我们想容让Apache在tcp端口81上聆听，我们可以利用semanage这个指令来新增一条规则批准此事：
#semanageport-a-thttp_port_t-ptcp81
Semanage端口–a（添加）–t（类型）–p（协议）端口号
你可以这样令SELinux完整地列出每个服务可访问的端口：
#semanageport-l
通过设置选项的二元值，你可以微调SELinux策略而不必重新编译策略的源代码。
这些选项包括允许用户在Samba下分享他们的主目录，或者允许Apache从用户的主目录伺服文件。
否则这些都会被SELinux策略所拒绝。
在某些情形下，上述方法都不能解决问题，而我们必须通过创建自定的策略模块来扩展SELinux策略，允许一组特定的状态出理。
其中一个例子就是在smtp邮件服务器上增加postgrey服务。
我们的smtp服务器须要通过一个Unix通讯端与postgrey沟通，但缺省的SELinux策略却禁止我们的smtp服务器如此做。
结果该服务会被SELinux所封锁。
这个问题不能通过更改或撤消文件的安全性脉络来解决，也没有可供切换二元值。
我们可以通过一个二元值来停止SELinux保护smtp服务器，这样总比完全停用SELinux好，但不太理想。
如果我们将SELinux切换至Permissive模式并让邮件服务器运行一段时间，我们便可以在允许访问的情况下记录SELinux的问题。
查看日志时，我们会看见以下SELinuxAVC信息：
type=AVCmsg=audit（1218128130.653:
334）:
avc:
denied
{connectto}for
pid=9111comm="
smtpd"
path="
/var/spool/postfix/postgrey/socket"
scontext=system_u:
postfix_smtpd_t:
s0tcontext=system_u:
initrc_t:
s0tclass=unix_stream_socket
{write}for
name="
socket"
dev=sda6ino=39977017
postfix_spool_t:
s0tclass=sock_file
接着我们可以用audit2allow来产生一组允许所需行动的策略规则。
我们我可创建一个本地的postgrey强制类型策略档（postgreylocal.te）：
#grepsmtpd_t/var/log/audit/audit.log|audit2allow-mpostgreylocal>
postgreylocal.te
#catpostgreylocal.te
modulepostgreylocal1.0;
require{
typepostfix_smtpd_t;
typepostfix_spool_t;
typeinitrc_t;
classsock_filewrite;
classunix_stream_socketconnectto;
}
#=============postfix_smtpd_t==============
allowpostfix_smtpd_tinitrc_t:
unix_stream_socketconnectto;
allowpostfix_smtpd_tpostfix_spool_t:
sock_filewrite;
在上面我们看见如何从audit.log筛选有关smtp服务器的问题，并将这些问题导向audit2allow，让它产生一组规则，是它认为可用来允许被SELinux策略所封锁的行动。
查阅这些规则时，我们可发现该smtp服务器想连接及写进一个Unix通讯端，而从日志里我们看见这个Unix通讯端正正是postgrey服务所聆听的那个。
既然这一些都合情合理，我们可以续继用audit2allow创建一个自定的策略模块，允许这些行动：
#grepsmtpd_t/var/log/audit/audit.log|audit2allow-Mpostgreylocal
还有个命令通过audit日志自定策略
通过audit日志，添加必要的selinux设定
cat/var/log/audit/audit.log|aduit2allow-Mcacti&
&
semodule-icacti.pp
接着我们利用semodule这个指令将我们的postgrey策略模块装入现有的SELinux策略内：
semodule-ipostgreylocal
如此便会将我们的postgrey策略模块新增到
/etc/selinux/targeted/modules/active/modules/postgreylocal.pp。
我们可以通过semodule-l来检查该策略模块已被正确地装入。
然后我们可以继续监视SELinux的日志来确定自定的策略模块有效用。
满意时，我们便可以重新启用SELinux的Enforcing模式，让功能已全备的smtp服务器再次享有SELinux的保障。
7.1.手动式自定策略模块
audit2allow在大多数情况下都可以自动创建一个自定策略模块来解决某个特定问题，但有时它未能完全正确，而我们也许会想以人手编辑并编译该策略模块。
就以下列的AVC审计日志为例
现在我们可以手动地编译及装入已修改的自定政策模块：
#checkmodule-M-m-opostfixlocal.modpostfixlocal.te
#semodule_package-opostfixlocal.pp-mpostfixlocal.mod
#semodule-ipostfixlocal.pppostdrop
升级会员 