dockerdaemon（dockerdaemon启动）

本篇文章给大家谈谈dockerdaemon，以及dockerdaemon启动对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、docker是干什么的
• 2、Cannot connect to the Docker daemon
• 3、docker daemon中的userland-proxy选项
• 4、理解Docker容器的进程管理
• 5、针对docker系统的渗透测试方法
• 6、干货来啦！带你初探Docker逃逸

docker是干什么的

docker是一个开源的应用容器引擎。裤瞎

让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发胡盯空布到任何流行的Linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。

众所周知，一个Java应用war包或者jar包启动成功，有能够对外提供服务的能力，能正常访问页面，做操作，需要部署到一台有tomcat的linux环境中，没有容器技术前的上线流程通常出现这样的或那样的问题。

docker的架构

Docker使用客户端服务器架构模式，使用远程API来管理和创建Docker容器，Docker容器通过Docker镜像来创建。容器则樱与镜像的关系类似于面向对象编程中的对象与类，Docker daemon一般在宿主主机后台运行，等待接收来自客户端的消息。Docker客户端则为用户提供一系列可执行命令，用户用这些命令实现跟Docker daemon交互。

Docker daemon作为服务端接受来自客户的请求，并处理这些请求创建、运行、分发容器。 客户端和服务端既可以运行在一个机器上，也可通过socket或者RESTfulAPI来进行通信。

Cannot connect to the Docker daemon

当用普通帐号而非root帐号使用docker时，如果你你遇到这个错误：

Cannot connect to the Docker daemon. Is the docker daemon running on this host

首先通过“sudo docker images”确定是不是权限问题导致的。如果不报错误，则需要‘sudo chmod 777 /var/run/docker.sock ’ 给所有人运行docker的消激权限，这个时候任何人都可以'docker images'等进行docker相关的操作了

其次如果不是权限问题导致的，则需要查看docker 进程是否已经正常拿碰袜启动，没有启动的原因是什么吵清，进行docker服务的恢复。

docker daemon中的userland-proxy选项

docker启动时可以在配置文件中指定启动项，如下：

新建/etc/default/docker文件，指定docker守护进程的启动配置：

从docker daemon的角度，添加了userland-proxy的起停开关

首先介绍userland-proxy一直以来的作用。众所周知，在Docker的桥接bridge网络模式下，Docker容器是通过宿主机上的NAT模式，搜码码建立与宿主机之外世界的通信。然而在宿主机上，一般情况下，进程可以通过三种方式访问容器，分别为：eth0IP:hostPort, containerIP:containerPort,以及0.0.0.0:hostPort。实际上，最后一种方式的成功访问完全得益于userland-proxy，即Docker Daemon在启动一个Docker容器时，每次为容器在宿主机上映射一个端口，都会启动一个docker-proxy进程，实现宿主机上0.0.0.0地址上对容器的访问代理。

当时引入userland-proxy时，也许是因为设计者意识到了0.0.0.0地世哪址对容器访问上的功能缺陷。然而，在docker-proxy加入Docker之后相当长的一段时间内。Docker爱好者普遍感受到，很多场景下，docker-proxy并非必需，甚至会带来一些其他的弊端。

影响较大的场景主要有两种。

第一，单个容器需要和宿主机有多个端口模敬的映射。此场景下，若容器需要映射1000个端口甚至更多，那么宿主机上就会创建1000个甚至更多的docker-proxy进程。据不完全测试，每一个docker-proxy占用的内存是4-10MB不等。如此一来，直接消耗至少4-10GB内存，以及至少1000个进程，无论是从系统内存，还是从系统CPU资源来分析，这都会是很大的负担。

第二，众多容器同时存在于宿主机的情况，单个容器映射端口极少。这种场景下，关于宿主机资源的消耗并没有如第一种场景下那样暴力，而且一种较为慢性的方式侵噬资源。

如今，Docker Daemon引入- -userland-proxy这个flag，将以上场景的控制权完全交给了用户，由用户决定是否开启，也为用户的场景的proxy代理提供了灵活性

原文地址：

理解Docker容器的进程管理

1.在Docker中，进程管理的基础就是Linux内核中的PID命名名空间技术，每个Container都是Docker Daemon的子进程，通过命名空间技术，Docker实现容器间的进程隔离。另外Docker Daemon也会利用PID命名空间的树状结构，实现了对容器中的进程交互、监控和回收。

2.在Docker容器中，PID1进程是启动进程，它也会负责容器内部进程管理的工作。竖启而这也将导致进程管理在Docker容器内部和完整操作余衡如系统上的不同。

3.如果在容器中运行多个进程，PID1进程需要有能力接管“孤儿”进程并回收“僵尸”进程--可利用自定义的init进程来进行进程管理，比如 S6 ， phusion myinit ， dumb-init , tini 等。

4.在Docker中“一个容器一个进程的方式”并非绝对化的要求，然而在一个容器中实现对于多个进程的管理必须考虑更多的细节，比如子进程管理，进程监控等等。所以对于常见的需求，比如日志收集，性拦行能监控，调试程序，我们依然建议采用多个容器组装的方式来实现。

针对docker系统的渗透测试方法

翻译总结于：《A Methodology for Penetration Testing Docker Systems》

    文章从两个攻击模型进行分析，结合错误配置和已知漏洞对docker渗透测试进行总结归纳，并给出了一份docker渗透测试检查清单。

    作者讨论了两种情况：在容器内和在容器外。在容器内部，攻击者会聚焦在逃逸隔离（即容器逃逸）。在容器外部，即宿主机上，攻击者还没有主机特权，这时候攻击者将会使用Docker（即Docker daemon攻击）来获得权限。

    容器逃逸重点在攻击和绕过隔离和保护机制，其中又可分成两种：一种是从容器逃逸到主机（CVE-2017-7308），另一种是从容器逃逸到另一个容器获取其中数据。

    作者从错误配置和安全漏洞两个角度对上述两个场景中的安全问题进行了梳理。漏洞问题是自身程序问题，错误配置更多的是用户使用问题。

    前两个错误配置与在主机上执行的Docker Daemon有关，其他错误配置与从容器内执行的容器逃逸攻击有关。

（2）可读写的Docker Socket：一些管理员设置了所有用户的读写权限，给了所有用户Docker Daemon的权限，尽管用户不在docker group也能使用docker。

（3）setuid bit：系统管理员在docker二进制文件上设置setuid位。setuid位是Unix中的权限位，它允许用户运行二进制文件而不是其本身作为二进制文件的所有者。如果和誉为docker二进制文件错误配置了setuid位，那么用户将能够以root身份执行docker。

（1）Container Escape Using the Docker Socket：如果/var/run/docker.sock作为volume挂载到容器上，那么容器中的进程可以完全访问主机上的docker。

（2）Sensitive Information：当容器可以访问/var/run/docker.sock时，用户可以查看现有容器的配置，其中可能包含一些敏感信息。

（3）Remote Access：如果没有配置docker API只监听本地主机，那么网络上的每个主机都可以访问docker，攻击者可以利用这种错误配置启动其他容器。

    亩兆文章中列举了一些最近的且已完全公开的可能在渗透测试期间使用的bug。

（1）CVE-2019-16884

（2）CVE-2019-13139

（3）CVE-2019-5736

（4）CVE-2019-5021

（5）CVE-2018-15664

（6）CVE-2018-9862

（7）CVE-2016-3697

    首先需要对目标系统执行侦查来收集数据，然后使用收集到的信息来识别弱点和漏洞。

（2）识别容器的操作系统（或者Docker镜像）

（3）识别主机操作系统：因为容器使用宿主的内核，所以可以使用内核版本来标识宿主信息，从而检测一些内核利用。

（4）读环境变量：环境变量是启动容器时与唤耐段容器通信信息的一种方式。当一个容器启动时，环境变量被传递给它，这些变量通常包含密码和其他敏感信息。

（5）检查Capabilities：通过查看/proc/self/status来查看容器的内核功能。其中CapEff是当前功能的值，可以使用capsh工具从十六进制值获取功能列表。可以使用这个来检查是否有可以用来容器逃逸的功能。

（6）检查特权模式：如果容器以特权模式运行，它将获得所有功能，因此可以通过查看能力（0000003fffffffff是所有能力的表示）来检查是否以特权模式运行进程。

（7）检查volumes：卷中可能包含敏感信息，可以通过查看挂载的文件系统位置来查看。

（8）检查挂载的docker socket

（9）检查网络配置

（2）拥有docker使用权限的用户

（3）配置：/etc/docker/daemon或/etc/default/docker

（4）可获得的镜像和容器

（5）iptables规则：使用 iptables -vnL 和 iptables -t nat -vnL，可以看到默认表filter和nat的规则。所有关于docker容器的防火墙规则都在filter中的docker -user链中设置。

干货来啦！带你初探Docker逃逸

Docker 是当今使用范围最广的开源容器技术之一，具有高效易用的优点。然而如果使用Docker时采取不当安全策略，则可能 导致系统面临安全威胁。

本期安仔课堂，ISEC实验室的张老师 将为大家介绍不同环境下， Docker逃逸至外部宿主机的情况。

一、配置特权模式时的逃逸情况

1.--privileged（特权模式）

特权模式于版本0.6时被引入Docker，允许容器内的root拥有外部物理机root权限，而此前容器内root用户仅拥有外部物理机普通用户权限。

使用特权模式启动容器， 可以获取大量设备文件访问权限 。因为当管理员执行docker run —privileged时，Docker容器将被允许访问主机上的所有设备，并可以执行mount命令进行挂载。

当控制使用特权模式启动的容器时，docker管理员可通过mount命令将碧游外部宿主机磁盘设备挂载进容器内稿慧迹部， 获取对整个宿主机的文件读写权限 ，此外还可以 通过写入计划任务等方式在宿主机执行命令 。

具体步骤如下：

1.以特权模式运行一个容器：docker run -it --privileged ubuntu:14.04 /bin/bash

2.查看磁盘文件：fdisk -l

3.此时查看/dev/路径会发现很多设备文件：ls /dev

4.新建目录以备挂载：mkdir /abc

5.将/dev/sda1挂载至 /abc: mount /dev/sda1 /abc

6.最终我们可以通过访问容器内部的/abc路径来达到访问整个宿主机的目的：ls /abc

7.尝试写文件到宿主机：echo 123 /abc/home/botasky/escape2

8.查看宿主机中的文件：ls /home/botasky/escape2

2.--cap-add与SYS_ADMIN

Linux内核自版本2.2起引入功能（capabilities）机制，打破了UNIX/LINUX操作系统中超级用户与普通用户的概念， 允许普通用户执行超级用户权限方能运行的命令 。

截至Linux 3.0版本，Linux中共有 38种capabilities。Docker容器默认限制为14个capabilities ，管理员可以使用--cap-add和--cap-drop选项 为容器精确配置capabilities 。

当容器使用特权模式启动时，将被赋予所有capabilities。此外，在--cap-add的诸多选项中，SYSADMIN意为container进程允许执行mount、umount等一系列系统管理操作，因此当容器以--cap-add=SYSADMIN启动时，也将面临威胁。

二、挂载配置不当时的逃逸情况

1.危险的Docker.sock

众所周知，Docker采用C/S架构，我们平常使用的Docker命令中，docker即为client，Server端的角色由docker daemon扮演，二者之间 通信方式有以下3种：

其中 使用docker.sock进行通信为默认方式 ，当容器中进程需在生产过程中与Docker守护进程通信时，容器本身需要挂载/var/run/docker.sock文件。

本质上而言，能够访问docker socket 或连接HTTPS API的进程可以 执行Docker服务能够运行的任意键并命令 ，以root权限运行的Docker服务通常可以 访问整个主机系统 。

因此，当容器访问docker socket时，我们可 通过与docker daemon的通信对其进行恶意操纵完成逃逸 。若容器A可以访问docker socket，我们便可在其内部安装client（docker），通过docker.sock与宿主机的server（docker daemon）进行交互，运行并切换至不安全的容器B，最终在容器B中控制宿主机。

具体步骤如下：

1.运行一个挂载/var/run/的容器：docker run -it -v /var/run/:/host/var/run/ ubuntu:14.04 /bin/bash

2.在容器内安装Docker作为client(此步骤可能需要更换源)：apt-get install docker.io

3.查看宿主机Docker信息：docker -H unix:///host/var/run/docker.sock info

4.运行一个新容器并挂载宿主机根路径：docker -H unix:///host/var/run/docker.sock run -v /:/aa -it ubuntu:14.04 /bin/bash

可以看见@符号后的Docker ID已经发生变化：

5.在新容器/aa路径下完成对宿主机资源的访问：ls /aa

三、存在Dirty Cow漏洞时的逃逸情况

1.脏牛漏洞(CVE-2016-5195)与VDSO(虚拟动态共享对象)

Dirty Cow（CVE-2016-5195）是Linux内核中的权限提升漏洞，源于Linux内核的内存子系统在处理写入时拷贝（copy-on-write, Cow）存在竞争条件（race condition），允许恶意用户提权获取其他只读内存映射的写访问权限。

竞争条件 意为任务执行顺序异常，可能 导致应用崩溃或面临攻击者的代码执行威胁 。利用该漏洞，攻击者可在其目标系统内提升权限，甚至 获得root权限 。 VDSO 就是Virtual Dynamic Shared Object（虚拟动态共享对象），即内核提供的虚拟.so。该.so文件位于内核而非磁盘，程序启动时，内核把包含某.so的内存页映射入其内存空间，对应程序就可作为普通.so使用其中的函数。

在容器中利用VDSO内存空间中的“clock_gettime() ”函数可对脏牛漏洞发起攻击， 令系统崩溃并获得root权限的shell，且浏览容器之外主机上的文件 。

2.PoC验证环境

GitHub上已有人提供了测试环境与PoC，我们可以通过以下命令获取。

1. 运行验证容器：docker-compose run dirtycow /bin/bash

2. 本地开启nc，进行观察（PoC中设置的反弹地址为本地的1234端口）：nc -lvp 1234

3. 编译PoC并运行，等待shell反弹：make ./0xdeadbeef

通过ID命令，可以发现这个shell为root权限：

参考引用

[img]

关于dockerdaemon和dockerdaemon启动的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。