|
原文译自:http://opensource.com/business/14/7/docker-security-selinux这篇文章基于我今年在DockerCon一个讲座,它将讨论我们当前听到的Docker容器的安全问题.Linux会保护你免于恶意软件的想法吧!你在乎吗?如果你不在一个多租户系统里运行Docker,并且你对运行在容器里的服务使用良好的安全策略,那你基本上不需要担心.仅仅假定运行在容器里的特权进程就像在容器外的特权进程一样.一些人错误的认为容器是一种比虚拟机更好更快的方式,但从安全的角度来看,容器更脆弱,这点我将在文章的后面说明.如果你相信我说的,Docker容器应该被视作"容器服务"-这意味着你要把运行Apache的容器看作在你的Host系统上运行的Apache服务,这就是说你要:尽快的降低特权尽可能以非root模式运行你的服务将容器里的root模式视为容器外的root模式目前我们正在通用规范中告诉人们把容器的特权进程当在容器外的特权进程.不要在你的系统里运行任意的Docker镜像,我从许多方面看到Docker容器革命类似于1999年的Linux革命,那时当一个管理员听到一个新的很酷的Linux服务时,他们会:去rpmfind.net和其他一些网站上去搜索包下载这些包通过RPM或make install来安装以管理者模式执行会出什么问题?两周后管理员听到一个zlib的脆弱性问题并不得不指出( 他们希望并祈祷不是), 软件是不安全的!这就是Red Hat发行版和其他一些值得信赖的第三方介入并拯救他们的时刻, Red Hat的企业版Linux给管理员提供了:一个提供下载的安全的repository安全的升级来修复问题发现问题并修复的团队管理/维护/安全增强的工程师团队通用的认证标准来检查OS的安全性问题只运行从可信赖组织获得的容器,我相信你应该继续从相同的人那边获得代码/包,就像你以前做的一样.如果代码不从那边来, 不要相信容器技术会保护你的主机.所以问题是什么? 为什么容器并不"包容"?最大的问题就是Linux的一切都不是命名空间 (namespaced). 现在, Docker使用5个命名空间来改变系统的进程: 进程, 网络, Mount, 主机名,共享内存.虽然有给用户一定的安全级别, 但无法像KVM实施全面的安全保护. 在KVM环境下进程不直接和主机的内核交互.它们也不访问内核的文件系统如/sys和/sys/fs, /proc/*设备结点是用于和VMs 内核交互的,而不是主机.因此, 想要越过VM来扩展特权级别, 进程要去攻击VM内核,找到HyperVisor的弱点,打破SELinux的控制(sVirt),最终攻击主机的内核.当你运行在一个容器里时,你就已经直接可以和主机的内核打交道了.没有被当成命名空间的主要的内核子系统如:SELinuxCgroups/sys下的文件系统/proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus没有被当成命名空间的设备:/dev/mem/dev/sd* 文件系统设备内核模块如果通过一个特权进程对以上的某个模块通信或攻击的话,你就拥有了整个系统.
(以上内容不代表本站观点。) --------------------------------- |
本網站是"非商業"(non-commercial)。
