本文翻译自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
上一篇 上传文件至服务器