SELinux 将保护您免受 chromium 社区创建的错误以及该浏览器的“糟糕”或“隐藏功能”。在安全方面，你不能把所有的鸡蛋都放在一个篮子里。在这里，禁用 selinux 可能不是一个好主意的一些示例：

• SELinux 正在阻止 chrome-sandbox 对文件 oom_score_adj 进行写访问——这是 Chromium 开发人员在出错时试图归咎于 selinux 的一种回归。它是在更新中引入的，Chromium 试图操纵 Out-Of-Memory。显然，它会被任何 MAC 系统拒绝，因为很明显，在 OOM 场景中将自己列为不是杀手的进程并不“酷”。
• SELinux 正在阻止 /opt/google/chrome/chrome-sandbox 对 oom_adj 进行“写入”访问- 在这种情况下，泄露的文件描述符会阻止 Chromium 在 OOM 案例中被杀死。很明显，这个错误会影响任何没有 SELinux 的系统。SELinux 阻止的回归/“隐藏功能”。
• “啊，啪！” 在启用 SELinux 强制的 Fedora 15 中的 openDatabase（例如，在加载 Twitter 时）中：当 Chromium 渲染将文件描述符传递给 chromium-sandbox 时，某些站点会崩溃。对文件标签的误解，可以通过restorecon -R ~/.config驱动 chromium 修复以在渲染某些站点时崩溃。显然，SELinux 防止了可能的损害的铬错误。如果您花时间阅读评论，您会注意到一些开发人员甚至不知道它为什么会崩溃，而其他开发人员则急于说“禁用 SELinux”。不爽...
• Fedora SELinux 启动 Chrome 的问题：在没有沙箱 ( ) 的情况下启动 chromiumgoogle-chrome --no-sandbox可以工作，而在升级到版本“14.0.803.0 dev”后使用沙箱则不行。Chromium 在编译时添加了 ASLR，但 SELinux 阻止了 text-relocations。SELinux 没有水晶球来猜测 Chromium 二进制文件file在浏览器添加此安全功能后被命令作为库进行探测，并且有责任阻止这种行为。Chromium 试图提高安全性，但忘记了那些文本重定位确实是编码错误的库的攻击媒介。
• 最好的：SELinux 阻止 google-chrome 读取 /etc/passwd 文件：这里不需要解释。为什么该死的浏览器要读取您的 passwd 文件？铬开发人员对此问题没有给出一致的解释。证明在这里。

SELinux 实际上提高了安全性并创建了另一个层来保护您免受 Chromium 升级中引入的损坏功能的影响。

默认策略应该阻止什么？

我将在其livejournal中引用 Dan Walsh 的话，他解释了 Chrome 政策的基础知识。这是在制定本政策之日给出的解释，基本上：

SELinux 阻止 chrome-sandbox：

• 使用网络

  • 它无法将文件复制到互联网

  • 它不能发送电子邮件并成为垃圾邮件机器人。

• 写在我的主目录的任何地方。或者系统上的几乎任何地方

• 读取我系统上的大多数位置

  • 像 mysql_db_t 一样，我可以拥有关键的系统数据

  • /etc/影子

  • ~/.ssh

  • ~/secret/DansPlanForWorldDomination.odp

强制执行最小权限，任何不允许的都将被阻止。因此，只要 chromium 实现与默认策略相冲突的新事物（请记住，SELinux 策略比您的浏览器更旧），它将获得 AVC。

这对 Chromium 来说还不错。这是任何受 SELinux 策略限制的软件的默认行为。

相关链接（附加文档）：

• Chrome 沙盒 SELinux
• SELinux 铬相关域
• chrome 进程的安全增强 Linux 策略