Articles from Dan Walsh

Keeping Up with Docker Security

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 »

Running Syslog Within a Docker Container

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...

Read More »

Yet Another Reason Containers Don't Contain: Kernel Keyrings

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!

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.

Read More »

Granting Rights to Users to Use Docker in Fedora

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 docker command line tool contacts the docker daemon process via a socket file /var/run/docker.sock owned by group docker. One must be member of that group in order to contact the docker -d process.

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.

Read More »

Docker's New Security Advisories and Untrusted Images

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.

Yawn!!!

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.

  • If you install an RPM or Debian package from an untrusted...
Read More »

Improving Docker Error Messages

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...

Read More »

Addressing Problems with Ping in Containers on Atomic Hosts

Having problems with ping in your containers? It might not be what you think!

Problem Statement

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).

Read More »

Hey Container Community, Let's Talk about Labels

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.

Read More »

Why Red Hat is Shipping Docker 1.6

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 »

Using Volumes with Docker can Cause Problems with SELinux

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.

Read More »

Why we don't let non-root users run Docker in CentOS, Fedora, or RHEL

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 »

Practical SELinux and Containers

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.

Read More »

Extending SELinux Policy for Containers

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.

Read More »

Looking forward to working with containerd

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 »

What does --selinux-enabled do?

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-enabled in 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-enabled to 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.

Read More »

Project Atomic Docker Patches

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 »

Better ways of handling logging in containers

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.

STDIN/STDERR messages in journal

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 »

Tightening Up SELinux Policy for Containers

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.

Read More »