Docker 运行具有 NET_ADMIN 功能的应用程序：涉及风险

Question

我正在尝试在 docker 容器中运行一个应用程序。该应用程序需要 root 权限才能运行。

sudo docker run --restart always --network host --cap-add NET_ADMIN -d -p 53:53/udp my-image

我的问题是：将 NET_ADMIN 功能与 --network 主机选项一起添加时有什么风险。

如果攻击者可以以某种方式从我的应用程序中获得一些代码执行，那么他是否拥有无限的权力，因为我以 root 身份运行它，还是他只能访问内核的网络部分？如果是这样，他的攻击面会是什么（换句话说，他能否仅使用 NET_ADMIN 功能集在我的主机操作系统上获得 root 权限？）

Answer 1

一季度。攻击者能否仅使用 NET_ADMIN 功能在我的主机操作系统上获得 root 权限？

是（在某些情况下）。

CAP_NET_ADMIN允许您SIOCETHTOOL在命名空间内的任何网络设备上使用ioctl()。这包括诸如ETHTOOL_FLASHDEV, ie 之类的命令ethtool -f。

这就是游戏。下面的引文中有更多的解释。

SIOCETHTOOL允许在任何网络命名空间内，因为提交 5e1fccc0bfac，“net：允许用户对网络堆栈核心的根控制”。在此之前，只能CAP_NET_ADMIN在“根”网络命名空间中使用。由于当时指出的安全考虑，这很有趣。我查看了 kernel version 5.0中的代码，我相信以下评论仍然适用：

回复：[PATCH net-next 09/17] net：允许用户对网络堆栈的核心进行 root 控制。

出于同样的原因，您最好根据 per-user_ns 对允许哪些 ethtool 命令非常有选择性CAP_NET_ADMIN。考虑一下：

ETHTOOL_SEEPROM=> 砖的 NIC
ETHTOOL_FLASHDEV=> 砖的 NIC; 如果系统不使用 IOMMU，则拥有该系统

默认情况下无法访问真实硬件，可以防止这些。物理网络接口必须移动到网络命名空间中才能访问它。

是的，我意识到这一点。问题是你是否希望容器中的任何东西都能做这些事情，即使分配了一个物理网络设备。

实际上我们在不考虑容器的情况下也有同样的问题 -CAP_NET_ADMIN真的应该仅仅因为它是网络硬件就给你对硬件的低级控制吗？我认为其中一些 ethtool 操作以及对非标准 MDIO 寄存器的访问可能需要额外的功能（CAP_SYS_ADMIN或CAP_SYS_RAWIO？）。

我猜锁定功能也有类似的问题。我在搜索时没有注意到结果中的锁定补丁。我想锁定功能的解决方案是某种数字签名，类似于锁定只允许签名的内核模块。

Q2。如果他们以某种方式从我的应用程序中获得了一些代码执行权，他们是否拥有无限的权力？

我将其拆分为一个更窄的案例，特定于您的命令 -

sudo docker run --restart always --network host --cap-add NET_ADMIN -d -p 53:53/udp my-image

除了功能之外，该docker命令还应施加 seccomp 限制。如果基于 LSM 的限制在您的系统（SELinux 或 AppArmor）上可用，它也可能会施加基于 LSM 的限制。但是，这些似乎都不适用于SIOCETHTOOL：

我认为seccomp-bpf可以用来阻止SIOCETHTOOL. 但是，docker的默认 seccomp 配置不会尝试过滤任何 ioctl() 调用。

而且我没有注意到我查看的内核函数中有任何 LSM 钩子。

我认为 Ben Hutchings 说得很好。理想的解决方案是将其限制为CAP_SYS_RAWIO. 但是如果你改变了这样的东西并且太多人“注意到”——即它破坏了他们的设置——那么你就会得到愤怒的莱纳斯对你大喊大叫:-P。（特别是如果您因为“安全启动”而从事此工作）。然后更改被恢复，你就可以找出最不丑陋的 hack 是什么。

即内核可能被迫保持向后兼容性，并允许具有CAP_NET_ADMIN根命名空间的进程。在这种情况下，您仍然需要seccomp-bpf保护您的 docker 命令。我不确定在这种情况下是否值得尝试更改内核，因为它只会保护（某些）容器。也许容器运行时docker可以被修复为SIOCETHTOOL默认阻止。对于像 LXC / systemd-nspawn 这样的“操作系统容器”来说，这也可能是一个可行的默认设置。