我想知道人们是否通常在默认情况下在安装SELinux的情况下禁用SELinux？如果可以，我们能否解释原因，系统是什么样的？

我想在此方面获得尽可能多的意见。

解决方案

我在这里没有太多贡献，但是由于它没有答案，我想我会投入两分钱。

就个人而言，当我处理不重要的事情时，我会在开发箱上将其禁用。当我处理任何生产或者需要更高安全性的产品时，我将其保留和/或者花时间对其进行调整以处理我需要的东西。

无论我们是否使用它，都取决于需求，但这是出于某种原因而创建的，因此请考虑使用它，而不要始终关闭它。

无论何时(噢，好)我们对某事物没有权限，SELinux都需要用户注意和手动授予权限。这样的许多人发现它会挡住并关闭它。

在最新版本中，SELinux更加用户友好，甚至有人谈论消除将其关闭或者隐藏的可能性，以便只有经验丰富的用户才能知道如何做到这一点，并且假定只有用户才是了解后果的人。

借助SELinux，存在一个鸡与蛋的问题：为了时刻保持这种状态，我们作为用户需要向开发人员报告问题，以便他们进行改进。但是用户不喜欢使用它，除非对其进行了改进，并且如果没有太多用户在使用它，它也不会得到改进。

因此，默认情况下将其保留为打开状态，以希望大多数人在关闭它之前会使用足够长的时间来报告至少一些问题。

最后，这是电话：我们是否正在寻找软件的短期修复或者长期的改进，这将导致不再需要有一天提这样的问题。

在三，四年前，我做到了，当时定义的策略有很多陷阱，创建策略太难了，我"没有时间"学习。当然，这不是在关键机器上。

如今，随着发布带有明智策略的发行版所做的所有工作，以及现有的可创建，修复和定义策略的工具和教程，没有任何理由可以禁用它。

我听说它越来越好，但是我仍然禁用它。对于服务器，除非我们是ISP或者希望在多个本地用户中实现细粒度访问级别控制的大型公司，否则这实际上没有任何意义。

在Web服务器上使用它时，apache权限存在很多问题。我要不断奔跑

chcon -R -h -t httpd_sys_content_t /var/www/html

添加新文件时更新ACL。我敢肯定，现在已经解决了这一问题，但是SELinux对于在标准网站部署中启用它所获得的有限回报感到非常痛苦。

我没有禁用它，但是有一些问题。

某些应用程序不能很好地使用它。

例如，我相信我使smartd能够尝试并跟踪我的
袭击磁盘状态，但selinux会对
在启动时创建了新的/ dev / sda *节点(我想这就是问题所在)

我们必须将源代码下载到规则中才能理解。

只需检查/ var / log / messages中是否存在" avc被拒绝"消息，我们便可以
可以解码被拒绝的内容。

Google" selinux常见问题"，我们会发现一个fedora selinux常见问题，它将
告诉我们如何解决这些问题。

去年，我在一家公司工作过，当时我们使用在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并通过其他公认的基于共识的最佳实践来强化他们的系统，例如Internet安全中心的基准测试(注意，他们推荐SELinux :-)。

在Red-hat下，我们可以编辑/ etc / sysconfig / selinux并设置SELINIX = disabled。

我认为，在所有版本的Linux上，我们都可以在lilo.conf或者grub.conf中的引导行中添加selinux = 0鼻子linux。

我公司生产CMS /集成平台产品。我们的许多客户都拥有传统的第三方系统，这些系统中仍然包含重要的运营数据，并且大多数客户希望继续使用这些系统，因为它们可以正常工作。因此，我们将系统连接起来，以通过多种方式提取数据以进行发布或者报告等。在每台服务器上运行大量客户端特殊功能，使得正确配置SELinux成为一项艰巨的任务，因此也是昂贵的任务。

许多客户最初希望获得最好的安全性，但是当他们听到我们的集成解决方案的成本估算时，" SELinux禁用"一词往往会很快出现在项目计划中。

真可惜，因为深入防御是个好主意。但是，SELinux从来就不需要安全性，这似乎是它的缺点。当客户问"如果没有SELinux，我们能确保它安全吗？"，我们该怎么回答？ "嗯……我们不确定"？

我们可以，但我们会的，但是当地狱死机，发现一些新漏洞，并且更新不及时时，系统很不幸地成为零基础... SELinux可能会救我们屁股。

但这是很难的。

可悲的是，我也经常关闭SELinux，因为大量的第三方应用程序(例如Oracle)在打开SELinux时不能很好地工作，并且/或者在运行SELinux的平台上不受支持。

请注意，红帽自己的Satellite产品也需要我们关闭SELinux，这再次令人遗憾地表示，人们在启用SELinux的平台上运行复杂应用程序时遇到了很多困难。

可能对我们有用或者无用的使用技巧：可以在运行时通过使用setenforce(使用getenforce检查当前状态)来打开和关闭SELinux。在chcon繁琐而ymmv的情况下，restorecon可能会有所帮助。

我从未禁用过selinux，我的承包商不得不使用它。而且，如果/当某些守护程序(具有OSS许可证btw)没有安全策略时，必须编写一个(良好)守护程序。这不是因为我认为selinux是Linux上无可争辩的MAC，无用举例说明，而是因为它无论如何都会提高操作系统的安全性。对于Web应用程序，OSS安全性更好的解决方案是mod_security：所以我同时使用两者。尽管近年来情况已大大改善，但selinux的大多数问题都涉及很少或者可理解的文档。

是的。脑死了它将破坏引入几乎无法诊断的标准守护程序。它也可以关闭一扇门，但不打开窗户。也就是说，由于某些原因，在新安装的CentOS上，它阻止了smbd从" /etc/init.d/smb"开始。但是它并没有阻止它在以" sh /etc/init.d/smb"或者" smbd -D"调用时启动，也不会阻止将init.d / smb文件移动到另一个目录，从该目录开始smbd美好的。

因此，无论它认为通过破坏系统来保护我们的系统正在做什么，都没有做到一致。咨询了一些认真的CentOS专家之后，他们也不了解其行为的不一致之处。它旨在使我们感到安全。但这是安全的基础。它可以代替执行锁定系统安全性的实际工作。

如果默认情况下处于打开状态，我将其保持打开状态直到出现问题为止，然后关闭它。

我个人认为它不提供任何安全性，我也不会打扰它。

我在开发机器上安装的CENTOS盒将其打开，然后将其关闭。它停止了我正在尝试测试正在开发的Web应用程序中要做的某些事情。该系统(当然)位于防火墙后面，该防火墙完全阻止了来自我们局域网外部的访问，并且具有许多其他安全措施，因此即使关闭SELinux，我也感到相当安全。

我曾经在一家主要的计算机制造商的公司工作过，该公司对在该公司的服务器上运行的RedHat Linux(以及其他两种版本)提供三级支持。在大多数情况下，我们关闭了SELinux。我的感觉是，如果我们确实需要SeLinux，则知道我们需要它，并且可以明确说明需要它的原因。当我们不需要它或者无法清楚说明原因时，并且默认情况下已启用它，我们很快就会意识到这是后端的痛苦。保持直觉。