☰

禁用/启用 SELinux 的原因

tag-icon • tag-icon linux security oracle redhat selinux
禁用/启用 SELinux 的原因

在这一方面问题在 StackOverflow 和我们这里完全不同的人群中，我想知道：您禁用 SELinux 的原因是什么（假设大多数人仍然这样做）？您想保持启用状态吗？在保持 SELinux 开启的情况下，您遇到了哪些异常？除了 Oracle，还有哪些供应商在支持启用 SELinux 的系统时遇到麻烦？

附加问题：有人设法让 Oracle 在 RHEL5 上使用 SELinux 强制目标模式运行吗？我的意思是，严格模式会很棒，但我认为目前还不可能，所以让我们先使用目标模式 ;-)

答案1

RedHat 默认启用 SELinux，因为它更安全。几乎每个使用 Redhat 衍生产品的供应商都启用了 SELinux离开因为他们不想花时间（因此也不想花钱）去弄清楚为什么这个东西不起作用。Redhat/Fedora 的人投入了大量的时间和精力，使 SELinux 成为企业中更可行的选择，但其他很多组织并不真正关心你的安全。（他们关心他们的安全性和其产品的安全声誉是完全不同的事情。

如果你能让它工作，那就去做吧。如果你不能，那么就不要指望供应商会提供很多帮助。你可能可以从 Redhat/Fedora 人员、selinux 邮件列表和 freenode 上的 #selinux 频道获得帮助。但是从 Oracle 这样的公司那里——嗯，SELinux 并不是他们商业计划中真正考虑的因素。

答案2

通常，您最好在 Permissive 模式下运行 SELinux，而不是完全禁用它。然后，您可以audit2why在一段时间后检查（通过）以查看在常规使用过程中会拒绝哪些类型的违规行为，audit2allow如果这些“违规行为”对您的设置来说是误报，则通过构建自定义策略。

我发现非 Fedora 衍生系统上的 SELinux 行为比默认的典型 Fedora/RHEL 系统上的行为要敏感得多。

如果你还没有看过，你可能会发现Fedora SELinux 用户指南教育性的。

答案3

的原因：

  • 通过强制访问控制提高安全性
  • 除了更高级别的安全性之外，您还需要其他理由吗？:-)

反对理由：

  • 难以理解
  • 难以管理
  • 难以排除故障

如果你正在考虑 SELinux，我推荐这本书SELinux 示例。

我曾在公司在每个系统上都启用了 SELinux 的强制模式。对我们来说，关键是理解和使用 audit2allow 程序，该程序可用于创建新的上下文规则。

首先，我们使用 audit2allow 生成一个模板，然后使用脚本来构建它，如下所示：

export NAME="my_serviced"
sudo audit2allow -m "${NAME}" -i /var/log/audit/audit.log > ${NAME}.te
sudo setup_semodule ${NAME}

setup_semodule 脚本：

#!/bin/sh

# Where to store selinux related files
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
NAME=$1

/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

这将从模板（.te 文件）构建模块，生成一个包，然后加载该模块。

我们使用 Puppet 作为我们的配置管理系统，并为 Puppet 编写了配置来管理这一切。

SELinux Puppet 模块：

答案4

我禁用了 SELinux应用装甲，我发现它比 SELinux 更加友好且易于维护。

相关内容