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