在Docker中运行特权容器很危险！！！

ang010ela 嘶吼专业版

文中所称Docker中的特权容器是指有host主机中root权限的容器，此类容器允许普通容器中无法访问的资源。特权容器的一个例子就是在Docker container中运行的Docker daemon，另一个例子是需要直接硬件访问的容器。最初，Docker-in-Docker的引入就是为了Docker的开发。但目前有很多运行特权容器的不同用例，比如在开源自动化服务器Jenkins中的自动持续集成(Continuous Integration)和交付(CI/CD)任务。但运行特权容器并不能保证其安全性。下面介绍下***者如何运行特权不安全的容器来获取后门。

特权容器的问题

一般只有在运行现有容器时同时需要派生另一个容器时才会使用Docker-in-Docker。但是在使用特权容器时仍然存在一些安全隐患。

运行特权容器时允许外部team访问host的资源，因此通过滥用特权容器，网络犯罪者可以获取资源的访问权限。当***者滥用特权容器进行***时，无需远程代码执行。但是在执行代码时，仍然存在很多的潜在***面。特权容器产生后，由于增强权限的许多，***者可能会以root权限运行代码。这表明***者可以以root权限运行主机，包括CAP_SYS_ADMIN。

***者在获取了暴露的特权容器访问权限后，就可以进一步发起很多***活动。***者可以识别出主机上运行的软件，并找出和利用相关漏洞。还可以利用容器软件漏洞或错误配置，比如使用弱凭证或没有认证的容器。由于***者有root访问权限，因此恶意代码或挖矿机都可以执行并有效地隐藏。

保持容器隔离

容器中含有应用的基本组件，必须是一个隔离的环境。为了隔离单个主机中运行的多个进程，容器使用了不同的kernel特征。由于Docker容器主要运行在Linux环境下，因此主要使用Linux Kernel的资源隔离特征来使其独立运行。其中一个特征就叫做Linux namespaces（命名空间）。下表是常见的命名空间类型。

表 1. Linux namespaces类型

默认情况下，Docker daemon和容器进程是以root权限运行的。从安全角度来看，应当创建另一个用户，并降低该用户的权限。

对特权容器来说，容器中包含有root权限表明也有host主机的root访问权限。虽然，容器进程默认情况下会有有限集的能力，如表2所示。但特权容器有所有的这些能力。

表 2. 以root权限运行的容器的能力

为了更加安全，Docker提供了一个以非root用户运行容器进程的选项，使用了Dockerfile中的USER。这里使用的并不是用户命名空间，它允许host的root用户和容器的root用户的隔离。用户命名空间可以在Docker daemon中配置，可能会其他许多需要root权限的情况下使用。

图 1. 表明用户命名空间默认情况下未使用的截图

因此，除非在–userns-remap flag中声明，否则Docker并不使用用户命名空间。

在用户命名空间中，进程可以被授予完全操作权限，但是在用户命名空间之外，进程并不会被授予相应权限。也就是说，在用户命名空间之外，进程有一个非特权的用户ID，而在命名空间中，用户ID为0。

也就是说即使进程是在新的用户命名空间中运行的，该操作也需要提升的权限，比如安装kernel模块，然后父用户命名空间就会被检查是否有相应的权限。如果没有找到，那么整个操作就会被拒绝。

虽然userns-remap提供了安全增强，但与rootless docker还是不同的，截至目前仍然是一个实验特征。Docker daemon，父容器进程，仍然在root权限下运行。

使用特权容器发起***

有了特权容器的这些能力，***者就可以尝试通过派生的特权容器来获取用户host环境的root权限。

近期，研究人员就在蜜罐系统中发现了***者通过派生的特权容器尝试将SSH公钥放入主机的/root/authorized_keys。

图 2. 恶意派生的特权容器代码截图

研究人员进一步分析发现，***者使用/mnt派生的容器尝试绑定到host root的 /目录。然后，研究人员发现执行了以下命令：

“Cmd”:[“sh”,”-c”,”mkdir -pv /mnt/root/; mkdir -pv /mnt/root/.ssh/; ls -ld /mnt/root/.ssh/; chattr -i -a /mnt/root/.ssh/ /mnt/root/.ssh/authorized_keys”]

移除不可变属性，并加到来自/mnt/root/.ssh和/mnt/root/.ssh/authorized_keys的后面：

图 3. 表明命令在派生的特权容器中执行的截图

需要说明的是图3中的代码表示的是Privileged: false，因为新的进程是在特权容器环境下执行的，其能力与之前派生的特权容器是匹配的。研究人员分析发现，“/”,”/mnt/root”绑定是与Docker CLI的 -v /:/mnt/root是等价的，主机的文件系统也是可以访问的。

***者可以尝试覆写SSH的authorized_keys 文件，可以从图4中的API请求中看到。

图 4. 尝试覆写authorized_keys的截图

以上例子表明，虽然有隔离，但***者仍然可以使用不同的方式来隔离容器，并获取host及其资源的访问权限，导致用户的基础设施被***。

Docker的–privileged flag禁用了所有的隔离特征。在应用了cgroups profiles后，容器可能有不同的PID和MNT命名空间。但在有–privileged flag的Docker容器中，用户或***者都可以有附加到主机的硬盘的访问权限。

–privileged flag和root access为***者逃逸隔离环境提供了大量选项：

· 挂载/dev/sda1，可以实现对主机存储单元的访问

ls –la /dev/mkdir /hdd & mount /dev/sda1 /hdd

· 使用cgroups notify_on_release和release_agent 来在host root中派生一个shell

· 应用定制的kernel模块和host上的驻留权限

特权Docker容器的安全建议

Tõnis Tiigi介绍了一种允许用户在无需root权限的情况下运行Docker daemon的rootless模式。通过rootless模式，***者可以从Docker daemon和容器中窃取信息，而且无需主机的root访问权限。但目前rootless模式并不支持完整的Docker suite特征，比如不支持：

· AppArmor

· Checkpoint

· Overlay network

· Exposing SCTP ports

开发者应当在使用特权容器时注意和进行一些限制。毕竟特权容器可以用作***入口，也可以用来传播恶意代码或恶意软件到被黑的主机。

研究人员给出了使用特权容易的一些安全建议：

· 最小权限原则。

· 网络连接应当加密。

· 容器应当被配置为只给予可信源访问权限。

· 遵循最佳安全实践。Docker提供了完整的最佳实践列表和内置了安全特征。

· 进行安全评估和安全审计。

注：本文翻译自：https://blog.trendmicro.com/trendlabs-security-intelligence/why-running-a-privileged-container-in-docker-is-a-bad-idea/

在Docker中运行特权容器很危险！！！