最近又翻译了一篇关于Docker的文章，内容是Docker发布的一个安全漏洞以及应对方法，地址在docker中文社区的《突破 DOCKER 容器的漏洞验证代码》


其实我十来年前做过一段时间的系统安全，还结识了安全圈里一帮兄弟，后来我转行做了存储，也一直在关注安全领域。这一两年安全行业迅猛发展，看得我有时候真是羡慕嫉妒恨啊......


回到技术话题，这个漏洞其实很容易理解。Linux上，每个进程除了根据运行者的uid进行权限识别，还有一组kernel capability，这一组在kernel代码里面以CAP_开头的宏更细致的定义了进程所拥有的权限。


而在容器也就是container内部，权限的设计就很复杂了。Container内运行的进程，本质上都直接运行在主机的内核空间中，和其他主机上的进程在内核中没什么区别，都有task_struct。所以为了限制container内进程的访问权限，让他们感觉自己运行在自己独立的空间中，就要在进程数据结构中设置特定的参数，在很多内核调用中，虚构返回。比如最基本的chroot()，让container进程只能将指定的目录当作根目录进行访问。


而***者（***）想要突破这个限制，要从container内部进程想办法访问到宿主系统的各种资源。最早最粗糙的***方式就是用各种特殊符号，比如“../../../../”。这种现在看起来搞笑的***方法在30年前UNIX上可是很奏效的，后来慢慢的很多简单的漏洞就被补上了。


具体到这个从docker的容器中访问到宿主系统的***方法，是利用了kernel的CAP_DAC_READ_SEARCH这个capability配合open_by_handle_at()这个系统调用。Docker 0.12之前的版本，在创建新的container之前，放弃了很多kernel的capability，却忘记了这一个，乃至于容器内的子进程都继承了这个cap。而拥有这个cap以后，通过指定inode的值，可以通过open_by_handle_at()这个系统调用直接打开inode值对应的文件，而不再是通过路径打开。而通常来说，/根文件系统的inode号是2.所以通过构造合理的参数，使用open_by_handle_at()，可以打开宿主系统的根目录。打开了根目录之后嘛，嘿嘿，就可以随意便利和打开下面的文件咯。


这里再贴个英文的关于该漏洞更详细的说明 Docker breakout exploit analysis


值得欣慰的是，从0.12版本以后，docker在创建新容器进程的时候，会放弃所有的kernel capability。这个问题就不存在啦。