如何减轻Docker容器中的特权升级以保护主机FS [英] How to mitigate privilege escalation in Docker Containers to secure the host FS

问题描述

关于安全性的问题。我想允许非root用户在某个集群上部署容器，因此我担心他们是否可以挂载主机目录，然后升级为容器内的root特权。我从下面的文章中收集到，用于将容器根用户映射到主机非根用户的功能仍然在以太网中？本文本身似乎还比较陈旧，我很好奇这些功能的开发情况。

Linux名称空间的最新改进将由于有了新的
用户命名空间，因此很快就可以运行没有root权限的
全功能容器了，这里将对此进行详细介绍，此外，这将解决
之间共享文件系统所引起的问题。主机和
来宾，因为用户名称空间允许容器
中的用户（包括根用户）映射到主机
系统中的其他用户。

因此，Docker的最终目标是实现另外两个
安全性改进：

1）将容器的根用户映射到Docker
主机的非root用户，以减轻容器到主机特权
升级的影响；

2）允许Docker守护进程无需root特权，
和委托操作就可以运行将这些特权授予经过良好审计的
子流程，每个子流程都有自己的（非常有限）范围：虚拟网络
设置，文件系统管理等。

https://docs.docker.com/articles/security /
http：/ /blog.docker.com/2013/08/containers-docker-how-secure-are-they/

解决方案

< blockquote>

我从下面的文章中收集到，用于将容器根用户映射到主机非根用户的功能仍然在以太坊中？

文章 用户名称空间已到达Docker！（ Phil Estes ， ESTESP ），说明它不再在ehter中！

将在docker 1.9的实验分支中可用（。 2014）。 PR 12648 。

确认用户映射：

用户名称空间最重要的功能之一是它允许容器具有不同的视图

具体来说，可以为进程（在我们的情况下为容器内部的进程）提供一组来自主机uid和gid空间，以便当进程认为它以uid 0（通常称为 root ）运行时，它实际上可能以uid 1000运行，或者10000，甚至34934322。这完全取决于我们在用户名称空间内创建流程时提供的映射。

当然，从安全的角度来看，这是一个很棒的功能，因为它允许我们的容器以root特权继续运行，但实际上并没有在主机上具有任何根特权。

请在 实验：用户名称空间支持文档页面（用于实验docker构建，来自 experimental.docker.com ）。

  docker daemon --userns-remap = default 
  

请注意，当运行启用了实验用户名称空间的Docker守护程序时，某些标准Docker功能当前不兼容，例如与主机（- -pid = host ，-net = host 等）或其他容器。

该用户映射功能目前仅针对每个守护程序，而不是针对每个容器（这需要Linux内核的改进，但尚需改进）。
与主机共享命名空间（--pid = host，-net = host等）

最后：

由于需要通过提供的映射将Docker守护程序本地层数据缓存中的内容隔离开来，因此，一旦使用了带有用户名称空间的实验性构建，根图目录的目录（默认为 / var / lib / docker ）将具有另一种间接级别，该级别与重新映射的根uid和gid相关。

例如，如果我提供给-userns-remap 标志的重新映射用户具有从属用户和组以ID 10000 开头的范围，则使用该重新映射设置运行的所有图像和容器的图形目录的根目录将位于 / var / lib中/docker/10000.10000 。

如果您使用实验性构建，但不提供用户名称空间重映射，则您当前的内容将迁移到 / var / lib / docker / 0.0 将其与重新映射的图层内容区分开。

2016年2月更新：

如 Phil E

过去一周，Docker 1.10发布了， 用户名称空间已作为一项功能包含在内。 。

快速说明一下，由于从实验级到熟练级的发展，文档现在位于守护程序命令行参考页中。

A question on secuity. I want to allow non-root users to deploy containers on say a cluster, I'd be concerned if they could mount host directories and then escalate to root privileges inside the container. I gather from the articles below that the feature for mapping a container-root-user to a host-non-root-user is still in the ether? The article itself seems to be relatively old, I'm curious to know how developed these features are.

"Recent improvements in Linux namespaces will soon allow to run full-featured containers without root privileges, thanks to the new user namespace. This is covered in detail here. Moreover, this will solve the problem caused by sharing filesystems between host and guest, since the user namespace allows users within containers (including the root user) to be mapped to other users in the host system.

The end goal for Docker is therefore to implement two additional security improvements:

1) map the root user of a container to a non-root user of the Docker host, to mitigate the effects of a container-to-host privilege escalation;

2) allow the Docker daemon to run without root privileges, and delegate operations requiring those privileges to well-audited sub-processes, each with its own (very limited) scope: virtual network setup, filesystem management, etc.

https://docs.docker.com/articles/security/ http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/

解决方案

I gather from the articles below that the feature for mapping a container-root-user to a host-non-root-user is still in the ether?

The article "User namespaces have arrived in Docker!" (Phil Estes, ESTESP), illustrates it is not in the ehter anymore!
It will be available in the experimental branch of docker 1.9 (Nov. 2014). PR 12648.

The user mapping is confirmed:

One of the most important features of user namespaces is that it allows containers to have a different view of the uid and gid ranges than the host system.
Specifically, a process (and in our case, the process(es) inside our container) can be provided a set of mappings from the host uid and gid space, such that when the process thinks it is running as uid 0 (commonly known as "root"), it may actually be running as uid 1000, or 10000, or even 34934322. It all depends on the mappings we provide when we create the process inside a user namespace.

Of course, it should be clear that from a security perspective this is a great feature as it allows our containers to continue running with root privileges, but without actually having any root privilege on the host.

See more at the "Experimental: User namespace support" documentation page (for an experimental docker build, from experimental.docker.com) .

docker daemon --userns-remap=default

Note that some of standard Docker features are currently incompatible when running a Docker daemon with experimental user namespaces enabled, like sharing namespaces with the host (--pid=host, --net=host, etc.) or with other containers.

That user mapping ability is for now per-daemon, not yet per container (that would require a Linux kernel evolution which be in the work, but not). sharing namespaces with the host (--pid=host, --net=host, etc.)

Finally:

Due to the need to segregate content in the Docker daemon’s local cache of layer data by the mappings provided, once you use an experimental build with user namespaces, the root of your graph directory (/var/lib/docker by default) will have one additional level of indirection which correlates to the remapped root uid and gid.

For example, if the remapping user I provide to the --userns-remap flag has subordinate user and group ranges that begin with ID 10000, then the root of the graph directory for all images and containers running with that remap setting will reside in /var/lib/docker/10000.10000.
If you use the experimental build but don’t provide user namespace remapping, your current content will be migrated to /var/lib/docker/0.0 to differentiate it from remapped layer content.

Update February 2016:

As noted in the comments by Phil E

As of this past week, Docker 1.10 was released, and user namespaces was included as a feature.
A quick note that because of the graduation from experimental to master, the documentation now resides in the daemon command-line reference page.

这篇关于如何减轻Docker容器中的特权升级以保护主机FS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！