The Atomic Host platform is now replaced by CoreOS. Users of Atomic Host are encouraged to join the CoreOS community on the Fedora CoreOS communication channels.
The documentation contained below and throughout this site has been retained for historical purposes, but can no longer be guaranteed to be accurate.
I’ve been working on the Project Atomic team at Red Hat on Security for Docker containers. In order to get the word out I have been writing a series of blogs on Docker Security for OpenSource.com. I’ve written two so far, and hope to have the third done soon.
The first post covers the fact that a privileged process within a container is the same from a security point of view as the security of...
Read More »Recently I received a bug report on Docker complaining about using rsyslogd within a container.
The user ran a RHEL7 container, installed rsyslog, started the daemon, and then sent a logger message, and nothing happened.
# docker run -it --rm rhel /bin/bash
# yum -y install rsyslog
# /usr/sbin/rsyslogd
# logger "this is a test"
No message showed up in /var/log/messages within the container...
I see people rushing to set up Web sites and PaaS Servers that allow random people to upload Docker container images, and I feel like I am the voice in the wilderness. Remember, containers do not contain!
As I stated in my posts on OpenSource.com, not all of the operating system is namespaced. Parts that are not namespaced can potentially allow containers to attack each other, or the host, or at the very least will allow leakage of information into the containers.
I saw on the docker-dev list someone was asking about Fedora documentation that described how you add a user to the docker group. The user wanted to allow his users to do docker search to try to find images that they could use.
From the Docker installation documentation regarding Fedora:
Granting rights to users to use Docker
Fedora 19 and 20 shipped with Docker 0.11. The package has already been updated to 1.0 in Fedora 20. If you are still using the 0.11 version you will need to grant rights to users of Docker.
The
dockercommand line tool contacts thedockerdaemon process via a socket file/var/run/docker.sockowned by groupdocker. One must be member of that group in order to contact thedocker -dprocess.
Luckily this documentation is somewhat wrong, you still need to add users to the docker group in order for them to use docker from a non-root account. I would hope that all Distributions have this policy.
Docker has released two CVEs with the newest version (docker-1.3.2) regarding two privilege escalation flaws. They are only an issue when running untrusted images.
I question whether they should be CVE’s at all. People need to realize that installing a Docker image is the equivalent of installing an RPM or a Debian .deb package.
It is always amazing how small things can aggravate you. One of the biggest irritants I have with docker is how it has handled the --help option.
It was sending docker --help and docker COMMAND --help to stderr. This caused Red Hat’s Quality Engineering (QE) teams headaches since they wanted to automate testing for things like new options, or making sure the options in the man page matched those...
Having problems with ping in your containers? It might not be what you think!
We received a bug report the other day with the following comment:
On a RHEL 7 host (registered and subscribed), I can use Yum to install additional packages from docker run ... or in a Docker file. If I install the iputils package (and any dependencies), the basic ping command does not work. However, if I use the busybox image from the public Docker index, its ping command works perfectly fine (on same RHEL 7 host).
I recently published a post on the Red Hat Developer Blog about the Atomic command that we’ve been working on for the last few months.
The Atomic command (/usr/bin/atomic) is a high-level, coherent entrypoint for Atomic Host systems, and aims to fill in the gaps in Linux container implementations.
Docker has added a new feature to allow alternate logging drivers, and soon you’ll be able to use journald as a supported driver.
With Docker 1.6 they support json-file, which is the old default, syslog, or no logging at all.
We have added a new tool called atomic which I announced last week.
The Atomic tool currently takes advantage of the Label patch in docker that allows developers shipping applications as container images, to add arbitrary labels to the images json data. We chose to use some top level names for identifiers. Right now, Labels support free-form text without any restrictions. This is good in that it’s flexible, but bad in that we want containers to be portable and tools like Atomic that make use of the Label should co-exist with other tools that may also use the Label.
We attempt to ship new versions of Red Hat Enteprise Linux Atomic Host (RHELAH) every six weeks. I am in charge of the Docker portion of each release. I also lead the team developing the atomic command. As a major component of the RHELAH release, we want to include the most recent Docker release possible to our users.
However, just because Docker releases a new version does not mean this instantly...
Read More »When using SELinux for controlling processes within a container, you need to make sure any content that gets volume mounted into the container is readable, and potentially writable, depending on the use case.
By default, Docker container processes run with the system_u:system_r:svirt_lxc_net_t:s0 label. The svirt_lxc_net_t type is allowed to read/execute most content under /usr, but it is not allowed to use most other types on the system.
I often get bug reports from users asking why can’t I use `docker` as a non root user, by default?
Docker has the ability to change the group ownership of the /run/docker.socket to have group permission of 660, with the group ownership the docker group. This would allow users added to the docker group to be able to run docker containers without having to execute sudo or su to become root. Sounds great…
Read More »
With Docker 1.10 approaching soon, I wanted to talk about one of the useful new features coming that makes it easier to run containers in read-only mode. Using the new --tmpfs you can run a container as read only, but still use writeable directories for things like /etc, /tmp or /run but discard changes when a container is stopped.
I was asked a question about running users inside of a docker container: could they still get privileges?
Before we begin, here is more background on Linux capabilities
We’ll start with a simple container where the primary process is running as root. One can look at the capabilities of the current process via grep Cap /proc/self/status. There is also a capsh utility.
I believe SELinux is the best security measure we currently have for controlling access between standard Docker containers. Of course, I might be biased.
All of the security separation measures are nice, and should be enabled for security in depth, but SELinux policy prevents a lot of break out situations where the other security mechanisms fail. With SELinux on Docker, we write policy that says that the container process running as svirt_lxc_net_t can only read/write svirt_sandbox_file_t by default (there are some booleans to allow it to write to network shared storage, if required, like for NFS). This means that if a process from a Docker container broke out of the container, it would only be able to write to files/directories labeled svirt_sandbox_file_t. We take advantage of Multi-Category Security (MCS) separation to ensure that the processes running in the container can only write to svirt_sandbox_file_t files with the same MCS Label: s0.
A developer contacted me about building a container that will run as a log aggregator for
fluentd. This container needed to be a SPC container that would manage parts of the host system, namely the log files under /var/logs.
Being a good conscientious developer, he wanted to run his application as securely as possible.
The option he wanted to avoid was running the container in --privileged mode, removing all security from the container. When he ran his container SELinux complained about the container processes trying to read log files.
I recently answered an email asking about –selinux-enabled in the docker daemon, I thought others might wonder about this, so I wrote this blog.
I’m currently researching the topic of
--selinux-enabledin docker and what it is doing when set to TRUE.From what I’m seeing, it simply will set context and labels to the services (docker daemon) when SELinux is enabled on the system and not using OverlayFS.
But I’m wondering if that is even correct, and if so, what else is happening when setting
--selinux-enabledto TRUE.
`--selinux-enabled on the docker daemon causes it to set SELinux labels on the containers. Docker reads the contexts file /etc/selinux/targeted/contexts/lxc_contexts for the default context to run containers.
Project Atomic’s version of the Docker-based container runtime has been carrying a series of patches on the upstream Docker project for a while now. Each time we carry a patch, it adds significant effort as we continue to track upstream, therefore we would prefer to never carry any patches. We always strive to get our patches upstream and do it in the open.
This post, and the accompanying document...
Read More »Traditional logging systems, like syslog, do not quite work by default with Containers. This is especially true if they are running without an init system in the container.
I recently received a bugzilla report complaining about logging inside of a docker container.
First the user complained about all of STDOUT/STDERR showing up in the journal. This can actually...
Read More »A number of folks have asked for my thoughts on the Docker containerd announcement last week. While containerd itself is not new, having been announced over a year ago, we were happy to see that Docker Inc. is now spinning this out as an independent project. This is aligned with Red Hat’s overall goal to drive open industry standards for Linux containers and the work that we’ve helped drive as a...
Read More »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.
Podman (formerly kpod) has been kicking around since last summer. It was originally part of the CRI-O project. We moved podman into a separate project, libpod. We wanted Podman and CRI-O to develop at their own pace. Both CRI-O and Podman work fine as independent tools and also work well together.
The goal of Podman (Pod Manager) is to offer an experience similar to the docker command line - to allow users to run standalone (non-orchestrated) containers. Podman also allows users to run groups of containers called pods. For those that don’t know, a Pod is a term developed for the Kubernetes Project which describes an object that has one or more containerized processes sharing multiple namespaces (Network, IPC and optionally PID).
Podman brings innovation to container tools in the spirit of Unix commands which do “one thing” well. Podman doesn’t require a daemon to run containers and pods. This makes it a great asset for your container tools arsenal.
I was presenting OpenShift and really the underlying container technology we are building CRI-O, Buildah and Podman to some customers the other day. After the presentation, one of the customers came over to me and said, the biggest problem they have with their users building containers, was they needed to use certificates in the container in order to access their software repositories. But they did not want the certificates to end up embedded in the containers. I pointed out that Red Hat’s version of Docker allowed you to do volume mounts into containers during a docker build. Also Buildah had the same functionality. But he pointed out that they did not want everyone of their engineers to have to add the volumes, or if they were running a container and wanted to update software and they forgot the volume mount then they could not access the certificates.