近日,一篇在Docker博客上發(fā)表的文章顯示,Docker的容器已經(jīng)被突破,并且能夠遍歷宿主機(jī)的文件了。由于Docker的輕量,快速等等優(yōu)點(diǎn),讓Docker在PaaS[注]領(lǐng)域愈發(fā)火熱,自然也就吸引了安全人員對其進(jìn)行研究。這篇文章無疑將Docker推進(jìn)了一個(gè)新紀(jì)元:放開應(yīng)用,想想安全。
不要給用戶root權(quán)限
該文章的作者強(qiáng)調(diào):只有在容器內(nèi)以 root 權(quán)限運(yùn)行不受信任的應(yīng)用程序,才有可能觸發(fā)這個(gè)漏洞。而這是我們不推薦的運(yùn)行 Docker Engine 的方式。
這句話可以分兩個(gè)層次來解讀,首先就是root權(quán)限的使用,其次是何為不受信任的應(yīng)用程序。
Docker并不是虛擬機(jī),Docker本來的用法也不是虛擬機(jī)。舉個(gè)簡單的例子,普通的虛擬機(jī)租戶root和宿主root是分開的,而Docker的租戶root和宿主root是同一個(gè)root。一旦容器內(nèi)的用戶從普通用戶權(quán)限提升為root權(quán)限,他就直接具備了宿主機(jī)的root權(quán)限,進(jìn)而進(jìn)行幾乎無限制的操作。這是為什么呢?因?yàn)镈ocker原本的用法是將進(jìn)程之間進(jìn)行隔離,為進(jìn)程或進(jìn)程組創(chuàng)建隔離開的運(yùn)行空間,目的就是為了隔離有問題的應(yīng)用,而進(jìn)程之間的限制就是通過namespace和cgroup來進(jìn)行隔離與配額限制。每一個(gè)隔離出來的進(jìn)程組,對外就表現(xiàn)為一個(gè)container(容器)。在宿主機(jī)上可以看到全部的進(jìn)程,每個(gè)容器內(nèi)的進(jìn)程實(shí)際上對宿主機(jī)來說是一個(gè)進(jìn)程樹。也就是說,Docker是讓用戶以為他們占據(jù)了全部的資源,從而給用戶一個(gè)“虛擬機(jī)”的感覺。
第二,何為不受信任的應(yīng)用程序?來源不明的應(yīng)用程序,或者二進(jìn)制代碼等等,以及有漏洞的應(yīng)用程序,都可以稱為不受信任的應(yīng)用程序。舉個(gè)例子,在Docker容器中只運(yùn)行基礎(chǔ)的Apache服務(wù)器和MySQL數(shù)據(jù)庫,可能大家認(rèn)為這樣的環(huán)境用root也沒問題,但是如果Apache或者M(jìn)ySQL有不為人所知的漏洞被利用,那么這兩個(gè)應(yīng)用也就成為了不受信任的應(yīng)用。因此在以root運(yùn)行應(yīng)用程序,或是在考慮安全環(huán)境的時(shí)候,需要以一切皆不可信的態(tài)度來對Docker環(huán)境進(jìn)行安全加固。
Docker安全要依靠輔助機(jī)制
該作者還強(qiáng)調(diào),如果堅(jiān)持要root權(quán)限使用 Docker Engine ,系統(tǒng)的安全性可能會(huì)受到一系列眾所周知的內(nèi)核安全漏洞的影響。因此特別建議:
· 在運(yùn)行 Docker Engine 的系統(tǒng)中同時(shí)運(yùn)行 AppArmor 或者 SELinux。
· 將機(jī)器分成不同的組,相互信任的容器劃在一組。
· 不要以 root 權(quán)限運(yùn)行任何不受信任的應(yīng)用程序。
在上述三條建議之上,還應(yīng)該有一種機(jī)制,就是保障機(jī)制。要不停的輪序去檢測,要能夠發(fā)現(xiàn)可疑的行為,并且對任何可疑的行為進(jìn)行反應(yīng)。比如進(jìn)程A并未給root權(quán)限,但是后來通過檢測機(jī)制發(fā)現(xiàn)它變成了root權(quán)限,我們就可以懷疑它是進(jìn)行了非法提權(quán)的操作。也就是說,我們允許你逃逸,但是我們也能夠在最短的時(shí)間內(nèi)發(fā)現(xiàn)你的逃逸行為,并且制止你。
此外,Docker在安全方面還存在亟待加固的點(diǎn):login過程使用明文傳輸用戶名和密碼,Image分發(fā)認(rèn)證、Docker對Host的逃逸(已公布的那個(gè)漏洞)、Docker內(nèi)給租戶的root賬號能否提供、Docker的配額限制(磁盤、網(wǎng)絡(luò))、Docker內(nèi)萬一提權(quán)后的限制(SELinux/AppArmor/GRSecurity)、出入Docker流量的監(jiān)控和審計(jì)、AUFS存在的攻擊點(diǎn)。
由于Docker需要把若干個(gè)container組一個(gè)虛擬的私有內(nèi)網(wǎng),解決租戶之間的網(wǎng)絡(luò)隔離。目前缺乏完整方案。從網(wǎng)絡(luò)性能來分析,現(xiàn)狀一般通過Docker Bridge或OVS實(shí)現(xiàn)NAT、用IPtable做隔離,性能堪憂,需要測試和驗(yàn)證。也有同仁表示性能衰減在50%以上。因此性能衰減嚴(yán)重也就可能成為一個(gè)新的攻擊平面。在網(wǎng)絡(luò)方面的攻擊點(diǎn)存在container之間的嗅探、ARP攻擊,IPtable的漏洞利用、對IPtable飽和攻擊等等。
當(dāng)然,絕大多數(shù)的Docker安全問題都是建立在被用在公有云[注]環(huán)境下的,如果Docker被使用在私有云[注]環(huán)境中,那么它所帶來的好處要遠(yuǎn)遠(yuǎn)多于他帶來的問題。