Docker安全性（一）——Docker容器真的安全嗎？

本文翻譯自Daniel J Walsh的一篇開源文章：http://opensource.com/business/14/7/docker-security-selinux

這篇文章是基於一個演講中”今年在我DockerCon上的分享”：http://v.youku.com/v_show/id_XODQwNjUwNTIw.html。

這將討論Docker容器的安全性，我們目前正在做什麼，和我們將朝哪裡走。

這是一個系列Docker安全的一部分，閱讀第二部分

 

容器不包含一切，包括安全

我聽到和讀到了很多人假定Docker的容器實際上是沙箱應用程式，這意味著他們可以在他們的系統以root身份執行的Docker隨機的應用程式。他們相信Docker容器實際上保護他們的主機系統。
•我聽到有人說，Docker容器同樣是安全的，因為在不同的虛擬機器/ KVM正在執行的程式。
•我知道人們正在下載隨機Docker映象，然後啟動他們自己的主機上。
•我甚至看到的PaaS伺服器（還不是OpenShift）可以讓使用者上傳自己的照片，以在多租戶系統上執行。
•我有一個同事誰說：“Docker即將執行從Internet下載的隨機程式碼，並作為root執行它”

“你能走進我的客廳裡？”蜘蛛對蒼蠅說。

停止假設Docker和Linux核心保護你免受惡意軟體侵害。

 

你關心嗎？

 

如果你是不是在多租戶系統執行Docker，你正在使用一個容器中執行的服務，良好的安全實踐，你也許並不需要擔心。姑且認為在容器內執行的特權程式是相同的執行在容器外部特權程式。

有些人做容器的認為比正在執行的虛擬機器的更好，更快的方法的錯誤。從安全的角度來看，容器要弱得多，我將在本文後面掩蓋。

如果你相信，我這樣做， – 意思視為執行Apache你把Apache服務的系統上執行的方式相同容器中Docker的容器應被視為“容器服務”，這意味著你會做以下幾點：
•儘快刪除許可權
•儘可能以非root執行您服務
•容器內款待root，就好像它是root容器的以外

目前，我們正在告訴人們在一般條件到一個容器內處理許可權的程式具有相同條件的容器外執行的特權程式。

不要在系統上執行隨機的Docker影像。在很多方面我看Docker容器革命類似於1999年左右的Linux的革命。在那個時候，當管理員聽到一個新酷Linux的服務，他們會：
•在像rpmfind.net的地方或者只是隨機的的網站在Internet上搜尋包
•下載程式到他們的系統
•如果通過RPM安裝或使安裝
•與特權執行它

 

怎麼會錯呢？

 

兩個星期後，管理員聽到關於zlib的脆弱性和具有搞清楚，如果，同時希望並祈禱這不是，他們的軟體是脆弱的！

這是Red Hat分發等少數可信方已加強在扭轉敗局。紅帽企業Linux管理員提供：
•一個值得信賴的儲存庫，他們可以從下載軟體
•安全更新修復漏洞
•一個安全響應小組發現和管理漏洞
•一個工程師團隊來管理/維護包和安全增強工作
•通用標準認證檢查作業系統的安全性

僅執行可信方容器。我相信你應該繼續從誰你已經從過去得到它一樣的人得到您的程式碼/包。如果程式碼不是來自內部或受信任的第三方，不靠容器技術來保護你的主機。

 

那麼，問題是什麼？為什麼容器中不包含那些內容？

 

最大的問題就是一切在Linux中沒有名稱空間。目前，Docker使用五個名稱空間來改變系統的流程檢視：過程，網路，安裝，主機名，共享記憶體。

雖然這些給使用者的安全性的某種程度它絕不是全面，像KVM。在KVM環境中虛擬機器程式不跟主機核心直接。他們沒有任何訪問核心的檔案系統，如/ sys和/sys/fs, /proc/*。

裝置節點用來交流核心的虛擬機器不是主機。因此，為了有一個特權提升了虛擬機器，該過程必須subvirt(一個基於虛擬機器的後門)虛擬機器的核心，發現在管理程式中的漏洞，通過SELinux的控制突破（sVirt），這是非常緊的在虛擬機器上，最後攻擊主機核心。

當你在一個容器中執行你已經讀懂了你在哪裡聊到主機核心。

主要的核心子系統都沒有名稱空間，如：
•SELinux的
•cgroup中
•在/ sys下的檔案系統
•/proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus

裝置沒有名稱空間：
•/ dev/ MEM
•/ dev/ SD*檔案系統裝置
•核心模組

如果你能溝通或攻擊的其中之一作為特權的過程中，你可以擁有自己的系統。

本文翻譯自Daniel J Walsh的一篇開源文章：http://opensource.com/business/14/7/docker-security-selinux

 

PPT的大概內容頁面：

Are Docker containers really secure?

Bringing new security features to Docker

How to grant rights to users to use Docker in Fedora

PPT的大概內容：

dockercon14 San Francisco June 9-10, 2014
 Docker and SELinux
Daniel J Walsh
Serior Principal Software Engineer
@rhatdan,danwalsh.livejournal.com,dwalsh@redhat.com

Containers do not contain

Do you care?

Everything in Linux is not namespaced
Not comprehensive like kvm
Kernel file systems:/sys,/sys/fs,/proc/sys
Cgroups,SELinux,/dev/mem,kernel modules

Treat container services just like regular services
Drop Privileges as quickly as possible
Run your services as non Root whenever possible
Treat root within a container as if it is root outside of the container
Don`t run random containers on your system
Only run containers from trusted parties

Overview of security within docker containers
Read only mount points
/sys
/proc/sys
/proc/sysrq-tigger
/proc/irq
/proc/bus

Capabilityies
man capabilities

Description
For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged process (whose

effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero).
Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process`s

credentials (usually: effective UID, effective GID, and supplementary group list).

Stating with kenel 2.2, Linux divedes the privileges traditionally associated with superuser into distinct units, know as capabilities, which can be

independently enabled and disabled. Capabilities are a per-thread attribute.

Capabliities removed
CAP_SETPCAP Modify process capablities
CAP_SYS_MODULE Insert/Remove kernel modules
CAP_SYS_RAWIO Modify Kernel Memory
CAP_SYS_PACCT Configure process accounting

…

SELinux gotchas
SELinux does not work with BTFS
Volume Mounts /var/lib/myapp
chcon -Rt svirt_sandbox_file_t/var/lib/myapp
Pull request for automatic labeling:
docker run -v /var/lib/myapp:/var/lib/myapp:Z …
docker run -v /var/lib/myapp:/var/lib/myapp:z …

Future
Ueser Name Space
libseccomp
–opt to all you to tighten security
–opt – Drop Capabilities
–opt – Alternate SELinux Types