不为(LXC)开发容器装载“`seccomp`”规则有多危险？

Question

为了便于使用/应用，许多管理员在容器化平台上关闭seccomp。

然而，关闭这样一个与沙箱紧密联系在一起的基本安全设置，在某种程度上是违背了容器化的目的的。从安全/稳定的角度来看，我认为在服务器上运行LXC/Docker容器时(按照/usr/share/lxc/config/common.seccomp中的LXC默认值配置)，继续将大多数系统调用列入黑名单是明智的：

2
blacklist
[all]
kexec_load errno 1
open_by_handle_at errno 1
init_module errno 1
finit_module errno 1
delete_module errno 1

问题

不“LXC容器装载seccomp规则”：

1. 重大*安全问题？
2. 其他技术(应用或稳定性)问题？

*额外的问题:假设一个人是唯一使用“母”系统及其LXC容器的人，风险是什么？(例如在一个实验测试实验室中，有多个用户可能不那么明显，但集装箱化仍然提供了许多好处，例如容易抓拍/克隆实验环境)？

Answer 1

安全并不像你所认为的那样是绝对的:没有任何东西本身是危险的，只有当考虑到特定的威胁时，事情才是危险的。

安全性只能针对可能影响平台预期使用的一组精确和实际的威胁来定义。

根据我的理解，您在问题中所说的是，您不打算将LXC用于安全目的(即。例如，您不依赖LXC来隔离受损的应用程序)，而是完全依赖LXC来简化本地个人实验环境的克隆和快照。

因此，唯一重要的是使用LXC可以以任何方式降低基础系统的安全性:答案是否定的，更糟糕的是，LXC不会提供安全好处，但不会降低基础系统的安全性(它将只具有与chroot相同的效果)。在启用LXC的计算机上运行应用程序，不会比在同一个系统上运行同一个应用程序而没有LXC更安全。

但是，不要忘记，如果使用LXC存储完整的Linux系统(我认为这是最常见的情况)，同样的安全卫生规则也适用于主机和来宾系统：

• 不要使用弱密码，
• 应用安全更新，
• 等。

对于开发机器，根据实际需要，可以通过防止通过网络访问LXC承载的服务来大大减少攻击面。通过将此类应用程序仅在本地接口上侦听，您将保持开发所需内容的能力，同时仍然确保远程攻击者不会利用您的工作中的某些缺陷或底层客户访问您的系统。

就技术应用/稳定性问题而言，我不知道有什么特别之处。如果遇到任何这样的问题，应该单独在Unix.SE或LXC邮件列表上处理。