2天时间,聊今年最热的 Agent、上下文工程、AI 产品创新等话题。2025 年最后一场~ 了解详情
写点什么

Docker 安全性探讨与实践:探讨篇

  • 2014-09-09
  • 本文字数:1768 字

    阅读完需:约 6 分钟

Daniel Walsh 是计算机安全领域的专家,有 30 余年的从业经验,非常熟悉容器技术。他 2001 年加入红帽公司,自 2013 年 8 月期任 RHEL Docker 增强开发团队主管。著名的 SELinux 项目就出自他手,该项目关注应用的运行空间和部署策略。Dan 还组织开发了安全虚拟化软件 sVirt,并创造了 SELinux 沙盒、Xguest 用户以及 Secure Kiosk。Dan 在今年七月参加 Docker 大会的时候做了一个主题演讲,解释了SELinux 的工作原理,Docker 如何在SELinux 下运行以及强制访问控制是如何增强Docker 安全性的。之后,基于这次演讲的视频,他又在开源网站上发表了两篇文章,一篇讨论Docker 的安全性,另一篇则着重介绍了RHEL 如何对Docker 的安全性进行了大量的增强。本文即是Dan 这两篇文章的梳理与讨论。

一、 容器的隔离能力不是万能的,应对才是王道

相信很多开发者都默认Docker 这样的容器是一种沙盒(sandbox)应用,也就是说他们可以用root 权限在Docker 中运行随便什么应用,而Docker 有安全机制能保护宿主系统。比如,有些人觉得Docker 容器里面的进程跟虚拟机里面的进程一样安全;还有的人随便找个源就下载没有验证过的Docker 镜像,看都不看内容就在宿主机器上尝试、学习和研究;还有一些提供PaaS 服务的公司竟然允许用户向多租户系统中提交自己定制的Docker 镜像。请读者注意,上述行为均是不安全的。

难怪有人说:“Docker 其实就是从网上不知什么地方下载一堆随机的代码,然后用root 权限运行。”现在Docker 镜像遇到的情景,跟1999 年Linux 兴起的时候类似:一个管理员觉得一个Linux 命令挺酷,就随便从网上什么地方找到这个命令的rpm 包,看都不看就安装运行。这显然是自取灭亡的典范。没过几天这个命令就爆出有bug,直接导致整个系统的瘫痪。

这种自取其辱的事情数不胜数,Dan 的团队乃至整个红帽公司,就在致力减少类似事件发生的概率。比如一定要从可信源下载软件,定期进行安全更新,长期维护一个安全应急小组以及验证系统安全性的一整套规程。

二、 我们需要在乎容器的安全性么?出乎意料但是显然需要

Dan 的团队近期不断提醒开发者,容器内外的权限基本没什么差别。如果开发者不是在多租户系统上运行 Docker,并且对 Docker 里面运行的服务都采取了很好的安全措施,那他们可能的确不用担心 Docker 爆出什么安全性问题,因为他们把 Docker 镜像内部和宿主环境同等对待了,这两者之间的安全性确实没什么差别。

但是难免有挺多开发者从直觉出发,觉得 Docker 容器的安全性就高,这些人往往会把 Docker 容器机制当作一种更快速部署虚拟机的方法。这时候就需要提醒他们安全性的问题了。从安全角度来看,容器的安全性非常弱。正常来讲,Docker 容器机制应该被当作一种服务来看待,就是说跑在 Docker 镜像上的 Apache 的安全措施,应该跟跑在自己服务器上的安全措施没什么区别才可以。比如,应该尽可能少的赋予软件各种权限,还应该总是用非 root 模式运行软件,以及万一在 Docker 内部用到了 root 权限,需要谨慎一如在宿主机上一样。

三、 是什么导致了安全漏洞?NameSpace

那么究竟是什么地方导致了 Docker 容器机制的安全问题呢?简单一句话,Linux 系统中不是所有东西都有命名空间(Namespace)。最新版本的 Docker 有五个命名空间:进程、网络、挂载、宿主和共享内存。如此简单的命名空间显然无法给开发者提供复杂的安全保护。比如在类似 KVM 的环境里,虚拟机根本无法直接和宿主的内核交互,它没有任何方式可以访问内核文件系统中如 /sys 和 /sys/fs 这样的地方。在这种情况下,想要脱离虚拟机来攻击宿主,比如要找到 HyperVisor 的弱点,攻克 SELinux 控制(这是个挺难的事情),然后才能够染指宿主的文件系统。而在 Docker 这样的容器里,原生就可以访问宿主的内核,安全性从何而来?

Dan 在文章中列举了主流的没有命名空间的内核,有:

  • SELinux
  • Cgroups
  • file systems under /sys
  • /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus

没有命名空间的设备有:

  • /dev/mem
  • /dev/sd* file system devices
  • Kernel Modules

如果开发者能访问或者攻击任何一个,就可以获得整个系统的控制权。


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-09-09 07:273435
用户头像

发布了 268 篇内容, 共 136.7 次阅读, 收获喜欢 24 次。

关注

评论

发布
暂无评论
发现更多内容

NocoBase 本周更新汇总:优化及缺陷修复

NocoBase

开源 低代码 零代码 无代码 版本更新

MSRC安全事件响应流程构建指南

qife122

网络安全 安全事件响应

springboot项目集成大数据第三方dolphinscheduler调度器 执行/停止任务

刘大猫

人工智能 算法 DolphinScheduler 调度器 大模型

VMware ESXi 8.0U3f macOS Unlocker & OEM BIOS 2.7 标准版和厂商定制版

sysin

esxi

ES 踩坑记:Set Processor 字段更新引发的 _source 污染

极限实验室

easysearch

烟草行业专卖人员画像与队伍考评系统上线运行

中烟创新

大数据-44 Redis 慢查询日志详解与性能优化实战指南

武子康

Java redis 大数据 分布式

跨越“演示”到“生产”鸿沟,亚马逊云科技开启AI Agents新纪元

Alter

AI agent

VMware ESXi 8.0U3f macOS Unlocker & OEM BIOS 2.7 集成网卡驱动和 NVMe 驱动 (集成驱动版)

sysin

esxi

征程 6 | UCP 任务优先级/抢占简介与实操

地平线开发者

自动驾驶 算法工具链 地平线征程6

理想汽车智驾方案介绍专题 1 端到端+VLM 方案介绍

地平线开发者

自动驾驶 端到端 算法工具链 地平线征程6

淘宝→拼多多/抖音/京东店铺迁移:API数据转换方案

tbapi

淘宝API 天猫API 淘宝商品详情API 天猫商品详情api

告别提示词工程,「上下文工程」才是 AI Agent 的核心竞争力

Baihai IDP

程序员 AI LLM AI Agent 上下文工程

VMware ESXi 8.0U2e macOS Unlocker & OEM BIOS 标准版和厂商定制版

sysin

esxi

VMware ESXi 9.0.0.0100 macOS Unlocker & OEM BIOS 2.7 集成网卡驱动和 NVMe 驱动 (集成驱动版)

sysin

esxi

动态写入Paimon表

Joseph295

Agno - 轻量级Python多智能体系统框架

qife122

人工智能 知识管理 Python框架

2个小时!我自己搭建了一套安全管理系统!

中烟创新

黄仁勋在北京链博会的演讲核心:AI变革性的到来

PowerVerse

从手写CRUD到一键生成:Sponge如何将Go开发效率推向新高度?

vison

后端 gin #go

行业AI先锋,为何网络先行?

脑极体

AI

新华视点:人工智能时代,我们需要怎样的人才 ?(附网易伏羲专家采访观点)

网易伏羲

大模型 网易伏羲 AI 智能体 群体智能

VMware ESXi 7.0U3w macOS Unlocker & OEM BIOS 2.7 标准版和厂商定制版

sysin

esxi

VMware ESXi 7.0U3w macOS Unlocker & OEM BIOS 2.7 集成网卡驱动和 NVMe 驱动 (集成驱动版)

sysin

esxi

VMware ESXi 9.0.0.0100 macOS Unlocker & OEM BIOS 2.7 标准版和厂商定制版

sysin

esxi

淘宝关键词搜索商品列表API接入指南(含Python示例)

tbapi

淘宝商品列表接口 天猫商品列表接口 淘宝关键词搜索接口

VMware ESXi 8.0U2e macOS Unlocker & OEM BIOS 集成网卡驱动和 NVMe 驱动 (集成驱动版)

sysin

esxi

Docker安全性探讨与实践:探讨篇_语言 & 开发_张天雷_InfoQ精选文章