Docker 執行具有 NET_ADMIN 功能的應用程序：涉及風險
我正在嘗試在 docker 容器中執行應用程序。該應用程序需要 root 權限才能執行。
sudo docker run --restart always --network host --cap-add NET_ADMIN -d -p 53:53/udp my-image我的問題是：將 NET_ADMIN 功能與 –network 主機選項一起添加時有什麼風險。
如果攻擊者能夠以某種方式從我的應用程序中獲取一些程式碼執行，那麼由於我以 root 身份執行它，他是否會擁有無限的權力，或者他是否只能訪問核心的網路部分？如果是這樣，他的攻擊面是什麼（換句話說，他可以在我的主機作業系統上獲得 root 權限嗎？只設置 NET_ADMIN 功能集？）
Q1。攻擊者能否僅使用 NET_ADMIN 功能在我的主機作業系統上獲得 root 權限？
是的（在某些情況下）。
CAP_NET_ADMIN允許您SIOCETHTOOL在命名空間內的任何網路設備上使用 ioctl()。這包括像ETHTOOL_FLASHDEVie這樣的命令ethtool -f。這就是遊戲。下面的引用中有更多解釋。
SIOCETHTOOL允許在任何網路命名空間內，因為送出 5e1fccc0bfac，“net：允許使用者對網路堆棧的核心進行根控制”。在此之前，只能CAP_NET_ADMIN在“根”網路命名空間中進行。這很有趣，因為當時指出了安全考慮。我查看了核心版本 5.0 中的程式碼，我相信以下評論仍然適用：關於：$$ PATCH net-next 09/17 $$net：允許使用者根控製網路堆棧的核心。
> > > > > > 出於同樣的原因，您最好根據 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 限制。如果您的系統（SELinux 或 AppArmor）上可用，它也可能會施加基於 LSM 的限制。但是，這些似乎都不適用於SIOCETHTOOL：我認為
seccomp-bpf可以用來阻止SIOCETHTOOL. 但是，docker 的預設 seccomp 配置不會嘗試過濾任何 ioctl() 呼叫。而且我沒有註意到我查看的核心函式中有任何 LSM 鉤子。
我認為 Ben Hutchings 提出了一個很好的觀點。理想的解決方案是將其限制為
CAP_SYS_RAWIO. 但是如果你改變了這樣的東西並且太多的人“注意到”——即它破壞了他們的設置——那麼你會得到憤怒的 Linus 對你大喊大叫:-P。（特別是如果您因為“安全啟動”而正在處理這個問題）。然後更改被恢復，你可以弄清楚最不醜陋的黑客是什麼。即核心可能被迫保持向後兼容性，並允許
CAP_NET_ADMIN在根命名空間中的程序。在這種情況下，您仍然需要seccomp-bpf保護您的 docker 命令。我不確定在這種情況下是否值得嘗試更改核心，因為它只會保護（某些）容器。也許像容器執行時這樣的容器docker可以被固定為SIOCETHTOOL預設阻塞。對於像 LXC / systemd-nspawn 這樣的“作業系統容器”，這可能也是一個可行的預設值。