一千萬個為什麽

搜索

在沒有root的情況下運行docker守護進程



Inspired by What are best and comprehensive practices to consider when running docker in production? , I stumbled over Why we don't let non-root users run Docker...

他們想出了 docker run -ti --privileged -v /:/ host fedora chroot/host ,它將你的非特權(但是 docker -grouped)用戶放在一個根目錄下外殼(不在容器中)。

沒必要提及,這對生產系統來說是一個壞消息。

可以做些什麽來避免這種或類似的事情?我認為docker守護進程不能作為非root用戶運行(否則這可能是啟動它的默認方式)?想到的一個解決方案並不是將無特權的用戶放在 docker 組中,只允許通過 sudoers 允許特定的docker命令行。但這足夠嗎?

我們是否知道如果圖像像往常一樣運行(例如, docker run --rm - >),那麽打破容器並獲得主機 root 它myimage )?我甚至沒有談論通過在容器中運行的服務來進行攻擊,而是通過特殊準備的圖像來進行攻擊。

編輯:澄清,我特別感興趣在這種攻擊情況:

  • Untrusted software developer delivers a ready-to-run image.
  • Trusted user runs that image on a production system in a normal fashion (i.e., docker --rm -it myimage), without --privileged.
    • Possibly with sub-scenarios of -u unprivileged_u or not.
  • Does the untrusted person that created the image have a reasonable chance to break out of the docker container runtime? I.e., more than with, say, classical chroot or classical permission elevation?

編輯2:我的研究只顯示了一個真正的突破事件,這個事件已經用Docker Engine 0.12修復,然後再次在1.0.1中修復。另外,我發現的所有事情都很重要,提到了docker守護程序的以前的TCP/IP接口,現在已經改變為Unix套接字很長一段時間了。還有其他什麽,或者只要輸入/運行實際的 docker 命令的人是好的,你會說沒有問題?

轉載註明原文: 在沒有root的情況下運行docker守護進程

一共有 1 個回答:

與僅僅將用戶添加到泊塢窗組相比,第二個鏈接解決方案不再更安全。

請註意,該頁面仍然可以使用 - 特權標誌啟動,並且它正在運行非限制。

<�代碼> unconfined_u:unconfined_r:unconfined_t </代碼>

這意味著容器可以訪問所有資源,包括主機磁盤和硬件。通過隱晦是安全,這不是安全。任何知道如何使用 mknod 或者遍歷/ sys和/ proc樹的人都可以輕松地通過零日誌記錄來妥協主機和所有容器。

實際情況是,碼頭工人既轉移了復雜性,又改變了安全邊界。所有可以啟動容器或點擊API的用戶都必須限制在該安全上下文中的可信用戶。

--privileged disables all apparmor and selinux policies which is actually far less secure than a native package.

命名空間不是一個安全功能,依賴於apparmor和selinux來執行合理的約束。

Docker在這個頁面上註明了這一點。

https://docs.docker.com/engine/security/security/#控制組

'首先,只有受信任的用戶才能被允許控制你的Docker守護進程。'

docker/kube的安全功能不像經典的unix權限那樣是行政邊界,它們是防止非特權容器爆發的工具。

在泊塢窗世界中,管理邊界成為主機,並且在該邊界內需要隔離應用程序或用戶所需的選擇和分段。

如果在考慮到這些變化的情況下實施這種復雜性和責任轉移的好處,通常會超過風險。

TLDR

Docker API用戶== Sudo所有用戶

使用--privlaged標誌==運行一個容器,以suid或root用戶身份運行Web服務。

根據OP的附加信息請求進行編輯

在OP的編輯中引用的問題是非高級uid0 權限升級。

不幸的是,由於需要執行根操作,因此Docker需要啟用一些功能,以便apt/dnf可以安裝軟件包等。

如果生產工作負載以此默認配置運行,並且應采用生產工作負載的最小特權安全原則,則此需求確實會造成風險。

--privileged disables apparmor/selinux and opens up capabilities

I am using ubuntu but it may be useful to work through the following steps. First start a default container with docker run -i --rm -t debian bash

從父主機使用 ps 查找bash的PID,並註意該進程歸屬於 root 。如果您查看/proc/$ PID/status ,您將看到它正在運行的上下文。

# egrep '^Cap(Prm|Inh|Eff)' /proc/16026/status
 CapInh:    00000000a80425fb
 CapPrm:    00000000a80425fb
 CapEff:    00000000a80425fb

您需要參考 man 7 man功能/usr/include/linux/capability.h 以獲取更好的信息,但是夏天是

CapInh =繼承的功能(docker提供的) CapPrm =由於權限(容器操作系統內部) CapEff =有效的能力

您可以通過運行以下內容將它們解碼為可讀的形式

$ capsh --decode=00000000a80425fb

Now do the same with $ docker run -i --rm --privileged -t debian bash and you will find that the effective capabilities are 0000003fffffffff

也只需在兩個虛擬機中執行 dir/dev ,您將看到特權容器的訪問權限。

通過查看 /etc/apparmor.d/docker 了解apparmor系統或SElinux中的標簽,您將看到其含義。

回到最小特權的原則,我會確保我的docker容器以非特權用戶的身份運行進程,並盡可能少地啟用功能。

作為一個例子,你可以通過首先刪除全部大寫來運行它來測試它。

$ docker run -i --rm -t --cap-drop=all -t debian bash

這可以通過上面的/proc/$ PID/status 方法進行驗證。

CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

Note it is all zeros, from CapInh. Then if I had to enable features for the application I would use --cap-add after the --cap-drop=all

例如, --cap-drop = all 會破解ping:

# ping -c 1 www.google.com
ping: Lacking privilege for raw socket.

So we can add the cap_net_raw cap. Docker expects the arguments with the cap_ prefix removed so the command is docker run -i --rm -t --cap-drop=all --cap-add=net_raw -t debian bash

# ping -c 1 www.google.com
PING www.google.com (216.58.216.164): 56 data bytes
64 bytes from 216.58.216.164: icmp_seq=0 ttl=54 time=4.779 ms

但要非常小心地添加它們作為示例。

cap_sys_module將允許容器從父主機添加或刪除內核模塊。

cap_sys_rawio將打開內存和所有塊設備進行攻擊

cap_sys_admin是超級危險的。

所以在這種情況下,我會看看你是否可以在這種情況下運行。

$ docker run -i --rm -t --cap-drop = all -u nobody:nogroup -t debian bash

希望apparmor和selinux配置文件的健壯性隨著時間的推移而改善,但如果這不足以滿足您的安全需求,您也可以在那裏查看。

真的,避免 - 特權標誌和使用最小特權原則將產生最大的影響。特別是如果您利用容器的短暫特性來保持軟件包保持最新狀態。

如果您需要更多紅帽涵蓋一些基本的seccomp選項。

https://access.redhat.com/documentation/ EN-US/red_hat_enterprise_linux_atomic_host/7/HTML/container_security_guide/linux_capabilities_and_seccomp