摘要：我們也不再需要提供的安全標(biāo)簽的策略了。增加容器之間的隔離度，甚至可以完全拋棄機(jī)制。禁止的越多越安全。例如的插件就得管管，畢竟插件都是來(lái)自互聯(lián)網(wǎng)，沒辦法保證的安全。在瀏覽器中使用執(zhí)行插件確保系統(tǒng)的安全。未來(lái)的我們將會(huì)繼續(xù)增強(qiáng)的安全功能。

當(dāng)我開始在opensource.com上面寫這一系列的docker安全的文章是，想闡述的一點(diǎn)就是：“他們快罩不住了(containers do not contain)”。

Docker 和 RedHat 的員工的工作之一就是讓這句話的正確性為0，我在redhat的團(tuán)隊(duì)就在嘗試采取其他的安全機(jī)制讓docker容器更加安全。我們正在進(jìn)行的計(jì)劃可能會(huì)對(duì)docker的將來(lái)產(chǎn)生影響。

//看上去像是UID映射這個(gè)東西=

用戶namespace基于內(nèi)核namespace，可以更好地將主機(jī)和容器分離起來(lái)。

基本方法就是宿主機(jī)創(chuàng)建一系列的UID，例如60000-61000，然后映射到內(nèi)部的namespace 0-1000，也可以用GID實(shí)現(xiàn)。內(nèi)核會(huì)把docker容器內(nèi)的UID 0 識(shí)別、鑒定為外部的UID 60000，任何一個(gè)沒有被映射過(guò)的進(jìn)程或者UID在容器內(nèi)部都會(huì)被識(shí)別為UID=-1,從而禁止他們?cè)L問容器，包括所有的鏡像都不允許訪問。如果你想使用有用戶namespace認(rèn)證的鏡像，那么你就得切換到容器內(nèi)部root用戶的UID對(duì)應(yīng)的外部ID。另一個(gè)問題就是外部UID 0掛載進(jìn)入容器的卷、硬盤等設(shè)備在容器內(nèi)部是沒有權(quán)限訪問的。你必須用chown命令將UID切換成內(nèi)部可以的UID。

chown -R 60000:60000 /var/lib/content

用戶namespace的另一個(gè)問題在于，你不許給不同的容器分配不同段的UID進(jìn)行映射。如果你有成百上千個(gè)容器，那么如何宿主機(jī)分配映射的UID就是個(gè)問題。

用戶namespace是一個(gè)很炫酷的事情，他們可以直接利用namespace的優(yōu)勢(shì)，如果把容器進(jìn)行如上的操作，那么我們可以拋棄掉所有的宿主系統(tǒng)提供的capabilities機(jī)制。也就是說(shuō)，當(dāng)用戶namespace生效后，我們可以完全不再需要宿主系統(tǒng)提供的capabilities機(jī)制。我們也不再需要selinux提供的安全標(biāo)簽的策略了。

三個(gè)可以用到用戶namespace的方案如下：

只映射UID=0。增加容器之間的隔離度，甚至可以完全拋棄capabilities機(jī)制。這樣做無(wú)疑可以增強(qiáng)容器和宿主機(jī)之間的安全性，但是也不會(huì)相對(duì)地提升容器之間的隔離度。所以只需要假設(shè)所有DOCKER容器的ROOT的外部UID為2，那么，外部的UID=2映射到容器內(nèi)部UID=0，外部GID=2映射到內(nèi)部GID=0，凡是大于2的全部映射到自己。這樣能最大程度的減少?gòu)娜萜鲀?nèi)部獲取宿主機(jī)的root權(quán)限。當(dāng)然這樣也能減少掛載文件系統(tǒng)時(shí)遇到的麻煩。這樣處理之后，內(nèi)部root用戶mount的磁盤，外部是無(wú)法讀取，（也就不會(huì)有SUID這個(gè)問題）。同樣，其余的關(guān)于用戶的namespace的處理也是一樣。

openshift式的解決辦法。每個(gè)容器都有自己多帶帶的UID/GID，如同每個(gè)用戶都有自己的UID和GID一樣。只有容器用得到內(nèi)核capabilities時(shí)這樣才有必要，用不到的時(shí)候意義不大。

按照段來(lái)映射。每個(gè)容器都映射一個(gè)UID段，每個(gè)容器映射的UID段各不相同。但是復(fù)雜性會(huì)隨著容器數(shù)目增加急劇增加。掛載文件系統(tǒng)可能會(huì)成為一個(gè)大問題?？梢栽黾右粋€(gè)功能，當(dāng)容器內(nèi)部mount的時(shí)候便執(zhí)行對(duì)應(yīng)的chown UID:GID /SRC命令，這樣一定程度上可以解決掛載的問題。

然而我不認(rèn)為這三個(gè)解決方案可以疊加。我也看過(guò)對(duì)內(nèi)核“加入容器時(shí)，重設(shè)mount目錄的UID的提議”，甚至對(duì)樂死mount --bind的命令也執(zhí)行重設(shè)UID，但是我覺得這個(gè)提議交給那些寫內(nèi)核的人比較好，我也會(huì)繼續(xù)參考那些做安全人的意見。

用戶namespace已經(jīng)并入libcontainer了，也已經(jīng)打好了能這樣讓docker運(yùn)行起來(lái)的補(bǔ)丁。

有個(gè)問題，那就是這里和別的地方提到的容器隔離措施全都是依賴與內(nèi)河?？諝夂碗娔X接觸，但是空氣無(wú)法和電腦內(nèi)核交流。但是容器就不一樣，所有的容器都是直接和內(nèi)核進(jìn)行交換信息。如果宿主機(jī)有個(gè)漏洞，那么這個(gè)漏洞就擊垮所有的安全措施，docker容器也會(huì)變得無(wú)法控制。

X86_64的linux內(nèi)核有超過(guò)600個(gè)系統(tǒng)調(diào)用。只要其中其中有一個(gè)有漏洞，那么都可以導(dǎo)致容器的權(quán)限提升。因此，有些系統(tǒng)調(diào)用是基本用不到的，所以應(yīng)該禁止使用這些系統(tǒng)調(diào)用。禁止的越多越安全。

Seccomp是google開發(fā)的禁止系統(tǒng)調(diào)用的沙盒類型的程序。例如Chrome的插件就得管管，畢竟插件都是來(lái)自互聯(lián)網(wǎng)，沒辦法保證100%的安全。Google在Chrome瀏覽器中使用Seccomp執(zhí)行chrome插件確保系統(tǒng)的安全。

我的同事Paul Moore，決定將Seccomp簡(jiǎn)化從而構(gòu)建一個(gè)C庫(kù)來(lái)管理系統(tǒng)調(diào)用庫(kù)。現(xiàn)在他的成果Libseccomp也在qemu，lxc，和systemd等軟件中開始使用了。

我們也開始用go封裝這個(gè)庫(kù)然后再libcontainer中調(diào)用，進(jìn)行過(guò)濾系統(tǒng)調(diào)用。

一般而言我們認(rèn)為這些系統(tǒng)調(diào)用是可以禁止容器調(diào)用的：kexec_load, open_by_handle_at, init_module, finit_module, delete_module, iopl, ioperm, swapon, swapoff, sysfs, sysctl, adjtimex, clock_adjtime, lookup_dcookie, perf_event_open, fanotify_init, kcmp.

我們也在尋求其他可以禁止的系統(tǒng)調(diào)用，歡迎給提議。除此之外，我們考慮禁止調(diào)用許多舊的網(wǎng)絡(luò)調(diào)用： Amateur Radio X.25 (3), IPX (4), Appletalk (5), Netrom (6), Bridge (7), ATM VPC (8), X.25 (9), Amateur Radio X.25 PLP (11), DECNet (12), NetBEUI (13), Security (14), PF_KEY key management API (15), 還有所有比 AF_NETLINK (16) 需求的權(quán)限更多的系統(tǒng)調(diào)用。

加入系統(tǒng)調(diào)用過(guò)濾器的另一個(gè)方面就是可以過(guò)濾掉所有非本架構(gòu)的調(diào)用，例如X86-64的電腦默認(rèn)情況下是無(wú)法使用32位的系統(tǒng)接口的。我們希望這個(gè)方案被設(shè)置成為seccomp的默認(rèn)選項(xiàng)。

禁止了其他架構(gòu)的系統(tǒng)調(diào)用，我們可以簡(jiǎn)單地認(rèn)為我們直接縮小了一半被內(nèi)核提權(quán)、內(nèi)核攻擊的風(fēng)險(xiǎn)。

類似于系統(tǒng)capabilities和selinux標(biāo)簽，我們?cè)试S使用命令行自己決定自己需要使用/禁止那些系統(tǒng)調(diào)用：

docker run -d --security-opt seccomp:allow:clock_adjtime ntpd

這條命令將會(huì)允許容器內(nèi)使用clock_adjtime調(diào)用，因?yàn)槭莕tpd服務(wù)，所以必須得用來(lái)調(diào)整時(shí)間。
同樣，

docker run -d --security-opt seccomp:deny:getcwd /bin/sh

這條命令將會(huì)禁止容器內(nèi)執(zhí)行的shell查詢當(dāng)前自己所在的目錄。redhat的Matt Heon有一個(gè)展示這個(gè)功能的短片。

視頻地址：https://www.youtube.com/watch?feature=player_embedded&v=sw3NjVMMXz8

我們默認(rèn)會(huì)禁止很多的系統(tǒng)調(diào)用，但是仍舊有很多很危險(xiǎn)的系統(tǒng)調(diào)用沒有被禁止。你可以全部禁止，然后慢慢地加入希望使用的系統(tǒng)調(diào)用。

docker run -d --security-opt seccomp:deny:all --security-opt seccomp:allow:getcwd /bin/sh

事實(shí)上，docker中運(yùn)行sh需要比getcwd更多的系統(tǒng)調(diào)用。被禁止掉的調(diào)用都會(huì)記錄在/var/log/autit/audit.log。如果audit沒有運(yùn)行的話，那么將會(huì)記錄在/var/log/messages中。

我們將會(huì)繼續(xù)增強(qiáng)docker的安全功能。如果linux內(nèi)核中出現(xiàn)新的安全功能，或者linux內(nèi)核中有安全功能的改進(jìn)，我們也會(huì)去盡量的利用這些功能，加固容器的安全性。

另一個(gè)方面是我們開始關(guān)注容器的管理。目前的管理方式是，如果你能有權(quán)限對(duì)docker的socket和端口發(fā)送數(shù)據(jù)的話，那么你就能對(duì)docker做任何事情。（譯注：尤其是端口，docker remote api這種東西目前完全是無(wú)法禁止的） 很遺憾的是目前我們的解決辦法只有禁止非root用戶的/run/docker.socket接口的訪問。我們也開始著手增加授權(quán)，這樣管理員就能證明自己是管理員，而不是有權(quán)力訪問接口的別的用戶。我們也開始增加適當(dāng)?shù)墓芾碛涗浀墓δ?，將管理員對(duì)某些容器的是否是特權(quán)運(yùn)行的情況記錄到syslog或者journalctl。除此之外，我們還可能增加基于角色的訪問控制（RBAC），簡(jiǎn)單的來(lái)說(shuō)，就是超級(jí)管理員控制其他的管理員。例如：

一星級(jí)管理員只允許開啟、停止容器。

二星級(jí)管理員有權(quán)利新建非特權(quán)的容器。

三星級(jí)管理員有最大的權(quán)力運(yùn)行所有的容器，并且賦予容器最大的權(quán)限。

當(dāng)這些安全措施實(shí)施之后，docker容器會(huì)更大程度的讓你的宿主機(jī)遠(yuǎn)離風(fēng)險(xiǎn)。我們的目標(biāo)就是讓容器能包含星辰大海。

  
原文 未來(lái)Docker的安全