本文翻譯自Daniel J Walsh的1篇開源文章:http://opensource.com/business/14/7/docker-security-selinux
這篇文章是基于1個演講中"今年在我DockerCon上的分享":http://v.youku.com/v_show/id_XODQwNjUwNTIw.html。
這將討論Docker容器的安全性,我們目前正在做甚么,和我們將朝哪里走。
這是1個系列Docker安全的1部份,瀏覽第2部份
我聽到和讀到了很多人假定Docker的容器實際上是沙箱利用程序,這意味著他們可以在他們的系統以root身份運行的Docker隨機的利用程序。他們相信Docker容器實際上保護他們的主機系統。
?我聽到有人說,Docker容器一樣是安全的,由于在不同的虛擬機/ KVM正在運行的進程。
?我知道人們正在下載隨機Docker鏡像,然后啟動他們自己的主機上。
?我乃至看到的PaaS服務器(還不是OpenShift)可讓用戶上傳自己的照片,以在多租戶系統上運行。
?我有1個同事誰說:“Docker行將運行從Internet下載的隨機代碼,并作為root運行它”
“你能走進我的客廳里?”蜘蛛對蒼蠅說。
停止假定Docker和Linux內核保護你免受歹意軟件侵害。
如果你是否是在多租戶系統運行Docker,你正在使用1個容器中運行的服務,良好的安全實踐,你或許其實不需要擔心。姑且認為在容器內運行的特權進程是相同的運行在容器外部特權進程。
有些人做容器的認為比正在運行的虛擬機的更好,更快的方法的毛病。從安全的角度來看,容器要弱很多,我將在本文后面掩蓋。
如果你相信,我這樣做, - 意思視為運行Apache你把Apache服務的系統上運行的方式相同容器中Docker的容器應被視為“容器服務”,這意味著你會做以下幾點:
?盡快刪除權限
?盡量以非root運行您服務
?容器內招待root,就好像它是root容器的之外
目前,我們正在告知人們在1般條件到1個容器內處理權限的進程具有相同條件的容器外運行的特權進程。
不要在系統上運行隨機的Docker圖象。在很多方面我看Docker容器革命類似于1999年左右的Linux的革命。在那個時候,當管理員聽到1個新酷Linux的服務,他們會:
?在像rpmfind.net的地方或只是隨機的的網站在Internet上搜索包
?下載程序到他們的系統
?如果通過RPM安裝或使安裝
?與特權運行它
兩個星期后,管理員聽到關于zlib的脆弱性和具有弄清楚,如果,同時希望并祈禱這不是,他們的軟件是脆弱的!
這是Red Hat分發等少數可信方已加強在改變敗局。紅帽企業Linux管理員提供:
?1個值得信賴的存儲庫,他們可以從下載軟件
?安全更新修復漏洞
?1個安全響應小組發現和管理漏洞
?1個工程師團隊來管理/保護包和安全增強工作
?通用標準認證檢查操作系統的安全性
僅運行可信方容器。我相信你應當繼續從誰你已從過去得到它1樣的人得到您的代碼/包。如果代碼不是來自內部或受信任的第3方,不靠容器技術來保護你的主機。
最大的問題就是1切在Linux中沒有命名空間。目前,Docker使用5個命名空間來改變系統的流程視圖:進程,網絡,安裝,主機名,同享內存。
雖然這些給用戶的安全性的某種程度它絕不是全面,像KVM。在KVM環境中虛擬機進程不跟主機內核直接。他們沒有任何訪問內核的文件系統,如/ sys和/sys/fs, /proc/*。
裝備節點用來交換內核的虛擬機不是主機。因此,為了有1個特權提升了虛擬機,該進程必須subvirt(1個基于虛擬機的后門)虛擬機的內核,發現在管理程序中的漏洞,通過SELinux的控制突破(sVirt),這是非常緊的在虛擬機上,最后攻擊主機內核。
當你在1個容器中運行你已讀懂了你在哪里聊到主機內核。
主要的內核子系統都沒有命名空間,如:
?SELinux的
?cgroup中
?在/ sys下的文件系統
?/proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus
裝備沒有命名空間:
?/ dev/ MEM
?/ dev/ SD*文件系統裝備
?內核模塊
如果你能溝通或攻擊的其中之1作為特權的進程中,你可以具有自己的系統。
本文翻譯自Daniel J Walsh的1篇開源文章: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⑴0, 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
上一篇 上傳文件至服務器