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