未加星标

Tightening Up SELinux Policy for Containers

字体大小 | |
[系统(linux) 所属分类 系统(linux) | 发布者 店小二04 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

I wrote a blog post a couple of weeks ago explaining how SElinux can block breakout of processes in containers using when exploiting a vulnerability in the /usr/bin/docker-runc or /usr/bin/runc executable. At the time, I explained that the policy for container_t was blocked from writing to most parts of the OS other the container content labeled container_file_t . Despite blocking writes, though, it still allowed reads of some files.

A few people were alarmed when they realized that SELinux would block the breakout on writes but there is a chance for information leakage into the container. The usual example was the ability to read /etc/passwd from the host. But this isn’t unlimited access to the host. If the same container processes tried to read /etc/shadow on the hosts, or content in users home directories, or database data in /var, they would be blocked.

Why is that allowed?

When writing SELinux policy for a general purpose process type, you always have a battle between security and usability. If you make the policy too tight, no one will use it. If you make it too loose, then it provides little additional security. Finding the sweet spot in the middle is difficult. The default SELinux policy allows this access for two main reasons.

The original policy for containers was written before docker for virt-sandbox. virt-sandbox was an effort to use libvirt-lxc tooling for splitting up the host OS Into several containers. Our idea at the time was to allow you to run multiple containers with a shared /usr and perhaps a shared /etc, but have each container have its own /var. The thinking was read only content in /etc is shared with unprivileged users, and an admin should control the data available in /etc. Think of having hundreds of containers each running the same apache services off of the host OS. Each one having their own private writable directories under /var. When docker came along, we decided to use the same policy mainly to allow people do things like:

docker run -v /etc/passwd:/etc/passwd rhel7 sh

Or

docker run -d -v /usr:/usr rhel7 /usr/bin/foobar

Also we saw people volume mounting in things like /etc/resolv.conf, /etc/hosts, /etc/localtime …

This allowed us flexibility on labeling, with limited exposure to information leak. Upstream docker now has the ability to relabel content on the host when running inside of a container.

Executing a command like the following:

docker run -d -v /var/lib/mariadb:/var/lib/madiadb:Z mariadb

Will cause the docker daemon to relabel the /var/lib/mariadb on the host to match the label of the container. But you would not want to do this with shared content in /etc.

Using the ‘:Z’ on /etc/passwd would be a bad idea.

docker run -v /etc/passwd:/etc/passwd:Z rhel7 sh

This command relabels /etc/passwd to a label that blocks access to other confined applications, potentially breaking those applications.

Since these issues have been pointed out I have decided to tighten the default policy by eliminating the container process types’ ability to read default labels in /etc. This will prevent a container process from being able to read /etc/passwd and other default files, but may cause certain issues when people want to volume mount in content from the hosts /etc directory. We will try this out in Rawhide and Fedora 26, and see if it does not cause issues, eventually back port it to RHEL.

本文系统(linux)相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统

主题: Linux
分页:12
转载请注明
本文标题:Tightening Up SELinux Policy for Containers
本站链接:http://www.codesec.net/view/535056.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(linux) | 评论(0) | 阅读(12)