ker安全性分析

一、在审查 Docker 的安全时，需要考虑三个主要方面：容器内在的安全性，由内核命名空间和cgroup中实现；docker 守护程序本身的攻击面; 加固内核安全特性，以及它们如何与容器中互动。Docker并不是虚拟机，Docker本来的用法也不是虚拟机。普通的虚拟机租户root和宿 主root是分开的，而Docker的租户root和宿主root是同一个root。一旦容器内的用户 从普通用户权限提升为root权限，他就直接具备了宿主机的root权限，进而进行几乎 无限制的操作。这是因为 Docker 原本的用法是将进程之间进行隔离，为进程或进程组 创建隔离开的运行空间，目的就是为了隔离有问题的应用，而进程之间的限制就是通过 namespace 和 cgroup 来进行隔离与配额限制。每一个隔离出来的进程组，对外就表现 为一个container（容器）。在宿主机上可以看到全部的进程，每个容器内的进程实际上 对宿主机来说是一个进程树。也就是说，Docker是让用户以为他们占据了全部的资源， 从而给用户一个“虚拟机”的感觉。二、安全策略 SELinux 或 AppArmor通过访问控制的安全策略，可以配置Linux内核安全模块，如安全增强型Linux（SELinux） 和AppArmor，从而实现强制性的访问控制（MAC）用以将进程约束在一套有限的系统资源 或权限中。如果先前已经安装并配置过SELinux，那么可以在容器使用setenforce 1来启用它。Docker 守护进程的SELinux功能默认是禁用的，需要使用-selinux-enabled来启用。容器的标签限制 可使用新增的-security-opt加载SELinux或者AppArmor的策略进行配置，该功能在Docker 版本 1.3 引入。例如：docker run -security-opt=secdriver:name:value -i -t centos bash namespaces 和 cgroupsDocker容器中非常相似LXC容器，它们都具有类似的安全功能。当以“docker run”启动一 个容器，后台Docker为容器创建一组namespaces和cgroups。cgroups 使用特定的命令行参数来启用一些资源限制，防止单一的容器用尽某个资源而使系 统瘫痪：CPU：docker run -it -rm -cpuset=0,1 -c 2 .内存：docker run -it -rm -m 128m .存储： docker -d -storage-opt dm.basesize=5G磁盘 I/O 挂载点使用原生容器库（如libcontainer）时，Docker会自动处理这项。但是，使用LXC容器库时， 敏感的挂载点最好以只读权限手动挂载，包括：/sys/proc/sys/proc/sysrq-trigger/proc/irq/proc/bus 挂载权限应在之后移除，以防止重新挂载。 Linux内核使用系统提供的更新工具（如 apt-get、yum 等）确保内核是最新的。过时的内核相比已公 开的漏洞危险性更大。使用GRSEC或PAX来强化内核，例如针对内存破坏漏洞提供更高的安全性。 libseccomp （和 seccomp-bpf 扩展）libseccomp库允许基于白名单方法来限制Linux内核的系统调用程序的使用。最好禁用受攻 击容器中对于系统操作不是很重要的系统调用程序，以防止其被滥用或误用。此功能目前正 在开发中（LXC驱动中存在，但是现在默认的libcontainer中没有）。使用LXC驱动程序14 来重启 Docker 程序：docker -d -e lxc如何生成seccomp配置的说明都在GitHub仓库的“contrib”文件夹。之后可用下面的命令 来创建一个以LXC为基础的Docker容器：docker run -lxc-conf=lxc.seccomp=$file 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=进行控制。例如： docker run -cap-drop setuid -cap-drop setgid -ti /bin/sh此功能在 Docker 1.2 版本引入。 完全虚拟化使用一个完全虚拟化解决方案来容纳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的操作时，系统可以检验其权限， t匕如发送一个信号或操作某个文件），同样用户组也要建立映射。映射之后，该用户在usernamespace中成为了 root而对应到外面的则是一个普通用户。2）非root运行Docker daemon:实现由普通用户启动Docker daemon和运行容器。Docker daemon守护进程目前需要root权限。首先，只有受信任的用户可以控制Docker守护进 程。Docker允许分享Dockerhost和容器之间的目录，且不限制容器的访问权限。比如容器中/host 目录将在host上的/目录下。并且容器将能够改变host的文件系统，没有任何限制。3）Docker的升级：要求重启或是升级docker，容器不会中断这个没找到4）磁盘限额：默认情况下，Docker容器跟host是共享同一个文件系统的。如果不对Docker容器做 磁盘大小的配额限制，容器就可能用完整个磁盘的可用空间，导致host和其他容器无法正常运作。cgroups来启用一些资源限制，防止单一的容器用尽某个资源而使系统瘫痪这些资源中包括磁盘。5）网络10 :目前同一台机器上的Docker容器会共享带宽，这样就可能出现某个容器占用大部分带宽 资源，从而影响其他需要网络资源的容器正常工作。由于Docker需要把若干个container组一个虚拟的私有内网，解决租户之间的网络隔离。目前缺 乏完整方案。从网络性能来分析，现状一般通过Docker Bridge或OVS实现NAT、用IPtable做 隔离，性能堪忧，需要测试和验证。也有同仁表示性能衰减在50%以上。因此性能衰减严重也就可 能成为一个新的攻击平面。在网络方面的攻击点存在container之间的嗅探、ARP攻击，IPtable 的漏洞利用、对IPtable饱和攻击等等。2. 通过监控容器的对CPU、memory、I/O、磁盘空间、网络、系统API等资源的使用情况，发现逃逸 的Docker容器，然后采取告警、停止容器、把容器迁移到沙箱中运行：cgroups不光追踪进程、还跟踪CPU、内存、块IO等使用信息，可以访问这些度量信息，并且获得 网络使用情况的度量信息，这些在纯粹的LXC上可以使用的同样也可以在docker上使用。