我去年在一家公司工作,我们在CentOS 5.x系统上启用了"有针对性"的政策.它没有干扰我们的开发人员所使用的任何Web应用程序代码,因为Apache处于默认策略中.它确实对从非Red Hat(或CentOS)软件包安装的软件带来了一些挑战,但我们设法通过配置管理工具Puppet解决了这个问题.
我们使用Puppet的模板功能来生成我们的策略.请参阅SELinux增强功能的Puppet,标题为"未来的东西",项目"策略生成".
以下是我们实现此方法的一些基本步骤.注意除了audit2allow之外,这都是自动化的.
为名为$ {name}的某个服务生成SELinux模板文件.
sudo audit2allow -m "${name}" -i /var/log/audit/audit.log > ${name}.te
创建一个脚本, /etc/selinux/local/${name}-setup.sh
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
/usr/bin/checkmodule -M -m -o ${BUILD}/${name}.mod ${SOURCE}/${name}.te
/usr/bin/semodule_package -o ${BUILD}/${name}.pp -m ${BUILD}/${name}.mod
/usr/sbin/semodule -i ${BUILD}/${name}.pp
/bin/rm ${BUILD}/${name}.mod ${BUILD}/${name}.pp
也就是说,大多数人最好只是禁用SELinux并通过其他普遍接受的基于共识的最佳实践来加强他们的系统,例如互联网安全中心的基准测试(注意他们推荐SELinux :-)).
我公司生产CMS /集成平台产品.我们的许多客户都拥有传统的第三方系统,其中仍然包含重要的操作数据,并且大多数客户希望继续使用这些系统,因为它们只是起作用.因此,我们通过各种方式将我们的系统挂钩,以便将数据拉出来进行发布或报告等 在每台服务器上运行大量客户端特定功能会使SELinux正确配置成为一项艰巨而且相应昂贵的任务.
许多客户最初都希望获得最佳的安全性,但当他们听到我们的集成解决方案的成本估算时,"SELinux禁用"这两个词往往会很快出现在项目计划中.
这是一种耻辱,因为深度防守是一个好主意.但是,SELinux绝不是安全所必需的,而这似乎是它的垮台.当客户问"如果没有SELinux你能保证安全吗？",我们应该回答什么？"嗯......我们不确定？"
我们可以而且我们会,但是当地狱冻结,并且发现了一些新的漏洞,并且更新时间不及时,并且您的系统不幸不足以成为零点...... SELinux可能会保存您的屁股.
但这是一个艰难的卖点.
我在这里没有太多贡献，但由于它没有得到答复，我想我会投入我的两分钱。
就我个人而言，我在开发盒上以及处理不重要的事情时禁用它。当我处理任何生产或需要更好安全性的事情时，我会将其保留和/或花时间调整它以按照我需要的方式处理事情。
天气或不使用它实际上取决于您的需求，但它的创建是有原因的，所以考虑使用它而不是总是关闭它。