问题导读:
1.Docker的安全问题来源于哪里?
2.通过攻击哪些模块会有失去对系统的控制的危险?
这篇文章基于我今年在DockerCon一个讲座,它将讨论我们当前听到的Docker容器的安全问题.
容器并不"包容"我听到也读到许多假定Docker容器是应用沙盒的观点--这意味着他们可以在他们的系统上使用有根权限的Docker来运行任意的程序. 他们相信Docker容器将会保护他们的主机系统.
- 我听到人们说Docker容器就像在VMs/KVM执行程序一样安全
- 我知道人们在随意的下载Docker镜像然后在他们的主机上执行
- 我甚至看到PaaS服务器(不是OpenShift)允许用户上传他们自己的镜像运行在多租户系统上
- 我有一个同事说道: Docker就是从网上下载任意的代码并以root模式运行
"你要来我的客厅吗", 蜘蛛对蝴蝶说道.
停止这种设为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),最终攻击主机的内核.
当你运行在一个容器里时,你就已经直接可以和主机的内核打交道了。
没有被当成命名空间的主要的内核子系统如:
- SELinux
- Cgroups
- /sys下的文件系统
- /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus
没有被当成命名空间的设备:
- /dev/mem
- /dev/sd* 文件系统设备
- 内核模块
如果通过一个特权进程对以上的某个模块通信或攻击的话,你就拥有了整个系统.
#############################################################
本文转自:http://blog.csdn.net/robertsong2004/article/details/38061989
|