docker安全性分析.docx

一、 在审查Docker的安全时，需要考虑三个主要方面： 容器内在的安全性，由内核命名空间和cgroup中实现; docker守护程序本身的攻击面; 加固内核安全特性，以及它们如何与容器中互动。Docker并不是虚拟机，Docker本来的用法也不是虚拟机。普通的虚拟机租户root和宿主root是分开的，而Docker的租户root和宿主root是同一个root。一旦容器内的用户从普通用户权限提升为root权限，他就直接具备了宿主机的root权限，进而进行几乎无限制的操作。这是因为Docker原本的用法是将进程之间进行隔离，为进程或进程组创建隔离开的运行空间，目的就是为了隔离有问题的应用，而进程之间的限制就是通过namespace和cgroup来进行隔离与配额限制。每一个隔离出来的进程组，对外就表现为一个container（容器）。在宿主机上可以看到全部的进程，每个容器内的进程实际上对宿主机来说是一个进程树。也就是说，Docker是让用户以为他们占据了全部的资源，从而给用户一个“虚拟机”的感觉。二、 安全策略l SELinux 或 AppArmor通过访问控制的安全策略，可以配置Linux内核安全模块，如安全增强型Linux（SELinux）和AppArmor，从而实现强制性的访问控制（MAC）用以将进程约束在一套有限的系统资源或权限中。 如果先前已经安装并配置过SELinux，那么可以在容器使用setenforce 1来启用它。Docker守护进程的SELinux功能默认是禁用的，需要使用-selinux-enabled来启用。 容器的标签限制可使用新增的-security-opt加载SELinux或者AppArmor的策略进行配置，该功能在Docker版本1.3引入。 例如： dockerrun-security-opt=secdriver:name:value-i-tcentosbashl namespaces和cgroupsDocker容器中非常相似LXC容器，它们都具有类似的安全功能。当以“docker run”启动一个容器，后台Docker为容器创建一组namespaces和cgroups。cgroups使用特定的命令行参数来启用一些资源限制，防止单一的容器用尽某个资源而使系统瘫痪：CPU： dockerrun-it-rm-cpuset=0,1-c2. 内存： dockerrun-it-rm-m128m. 存储： docker-d-storage-optdm.basesize=5G 磁盘I/Ol 挂载点 使用原生容器库（如libcontainer）时，Docker会自动处理这项。 但是，使用LXC容器库时，敏感的挂载点最好以只读权限手动挂载，包括： /sys/proc/sys /proc/sysrq-trigger/proc/irq /proc/bus 挂载权限应在之后移除，以防止重新挂载。l Linux内核使用系统提供的更新工具（如apt-get、yum等）确保内核是最新的。过时的内核相比已公开的漏洞危险性更大。使用GRSEC或PAX来强化内核，例如针对内存破坏漏洞提供更高的安全性。l libseccomp（和seccomp-bpf 扩展） libseccomp库允许基于白名单方法来限制Linux内核的系统调用程序的使用。最好禁用受攻击容器中对于系统操作不是很重要的系统调用程序，以防止其被滥用或误用。 此功能目前正在开发中（LXC驱动中存在，但是现在默认的libcontainer中没有）。使用LXC驱动程序14来重启Docker程序： docker-d-elxc 如何生成seccomp配置的说明都在GitHub仓库的“contrib”文件夹。之后可用下面的命令来创建一个以LXC为基础的Docker容器： dockerrun-lxc-conf=lxc.seccomp=$filel Capabilities 尽可能降低Linux能力。Docker默认的能力包括：chown、dac_override、fowner、kill、setgid、setuid、setpcap、net_bind_service、net_raw、sys_chroot、mknod、setfcap、和audit_write。 在命令行启动容器时，可以通过-cap-add=或-cap-drop=进行控制。 例如： dockerrun-cap-dropsetuid-cap-dropsetgid-ti/bin/sh 此功能在Docker 1.2版本引入。l 完全虚拟化 使用一个完全虚拟化解决方案来容纳Docker，如KVM。如果容器内的内核漏洞被发现，这将防止其从容器扩大到宿主上。 如同Docker-in-Docker工具所示，Docker镜像可以嵌套来提供该KVM虚拟层。三、 Docker在安全方面还存在亟待加固的点：login过程使用明文传输用户名和密码Image分发认证Docker对Host的逃逸（已公布的那个漏洞）Docker内给租户的root账号能否提供出入Docker流量的监控和审计AUFS存在的攻击点。 附：对于提出的遗留问题的反馈：1. 业界Docker安全遗留问题：1) user namespace隔离：这个可以使host的非root用户映射到容器中的root用户User namespace是Linux的六个namespace中最后一个支持的，并且直到Linux内核3.8版本的时候还未完全实现（还有部分文件系统不支持）。因为user namespace实际上并不算完全成熟，很多发行版担心安全问题，在编译内核的时候并未开启USER_NS。实际上目前Docker还不支持user namespace，但是预留了相应接口，相信在不久后就会支持这一特性。一个普通用户的进程通过clone()创建的新进程在新user namespace中可以拥有不同的用户和用户组。这意味着一个进程在容器外属于一个没有特权的普通用户，但是他创建的容器进程却属于拥有所有权限的超级用户。创建的user namespace内部的初始user和其外部namespace某个用户需要建立映射（这样可以保证当涉及到一些对外部namespace的操作时，系统可以检验其权限，比如发送一个信号或操作某个文件），同样用户组也要建立映射。映射之后，该用户在user namespace中成为了root而对应到外面的则是一个普通用户。 2) 非root运行Docker daemon:实现由普通用户启动Docker daemon和运行容器。Docker daemon守护进程目前需要root权限。首先，只有受信任的用户可以控制Docker守护进程。Docker允许分享Docker host和容器之间的目录，且不限制容器的访问权限。比如容器中/host目录将在host上的/目录下。并且容器将能够改变host的文件系统，没有任何限制。3) Docker的升级：要求重启或是升级docker，容器不会中断这个没找到4) 磁盘限额：默认情况下，Docker容器跟host是共享同一个文件系统的。如果不对Docker容器做磁盘大小的配额限制，容器就可能用完整个磁盘的可用空间，导致host和其他容器无法正常运作。cgroups来启用一些资源限制，防止单一的容器用尽某个资源而使系统瘫痪，这些资源中包括磁盘。5) 网络IO：目前同一台机器上的Docker容器会共享带宽，这样就可能出现某个容器占用大部分带宽资源，从而影响其他需要网络资源的容器正常工作。由于Docker需要把若干个container组一个虚拟的私有内网，解决租户之间的网络隔离。目前缺乏完整方案。从网络性能来分析，现状一般通过Docker Bridge或OVS实现NAT、用IPtable做隔离，性能堪忧，需要测试和验证。也有同仁表示性能衰减在50%以上。因此性能衰减严重也就可能成为一个新的攻击平面。在网络方面的攻击点存在container之间的嗅探、 ARP攻击，IPtable的漏洞利用、对IPtable饱和攻击等等。2