Exercise 1.8 - SELinux

Return to Workshop


Exercise 1.8 - SELinux

Exercise Description

Let’s move on to Security Enhanced Linux (SELinux). We will cover SELinux basics, Docker SELinux security policy and the "SELinux Coloring Book."

Section 1: Basics of SELINUX

In this section, we’ll cover the basics of SELinux and containers. 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 files with the svirt_sandbox_file_t label.

Step 1. Create the following directories.

Setup directory and file
mkdir ~/selinux
cd  ~/selinux
mkdir data
echo "SELINUX" > data/file1.txt
cat data/file1.txt
Get SELinux policy
sestatus | grep mode

Step 2. Attempt to cat out the file

Try to cat out the file
sudo docker run -v $(pwd)/data:/data fedora cat /data/file1.txt

This action will result in a Permission denied error. You can see the reason by inspecting the folder’s security context:

ls --scontext data

The label for the data doesn’t match the label for containers. The fix is to apply the container label to the data by using the chcon tool, effectively notifying the system that you expect these files to be consumed by containers:

Step 3. Find the selinux file context associated with containers.

Find the Containers Labels
sudo semanage fcontext --list | grep svirt

The containers should be running at svirt_sandbox_file_t

Step 4. Apply the container label to the data, using the chcon tool

Re-label the data dir
chcon -Rt svirt_sandbox_file_t data

Step 5. Try to cat out the file again from the container.

Run docker again

Step 6. Append text from the container to the file

Append text
sudo docker run -v $(pwd)/data:/data fedora sh -c 'echo "Thank You For Attending" >> /data/file1.txt'

Section 2: Docker SELinux Security Policy

The Docker SELinux security policy is similar to, and is based on, the libvirt security policy.

libvirt Policy

The libvirt security policy is a series of SELinux policies that defines two methods of isolating virtual machines. Generally, virtual machines are prevented from accessing specific parts of the network. Specifically, individual virtual machines are denied access to each other’s resources.

Red Hat extends the libvirt-SELinux model to Docker. The Docker SELinux role and Docker SELinux types are based on libvirt. For example, by default, Docker has access to /usr/var/ and some other locations, but it has complete access to things that are labeled with svirt_sandbox_file_t.

https://www.mankier.com/8/docker_selinux - this explains the entire Docker SELinux policy. It is not in layman’s terms, but it is complete.


^      ^           ^          ^     ^--- unique category
|      |           |          |----  secret-level 0
|      |           |--- a shared type
|      |---SELinux role
|------ SELinux user

The category system isolates containers from one another.

If a file is labeled svirt_sandbox_file_t, then by default all containers can read it. But if the containers write to a directory that has svirt_sandbox_file_t ownership, they write using their own category (which in this case is c186 , c641). If you start the same container twice, it will get a new category the second time (a different category than it had the first time).

Types can be applied to processes and to files.

Section 3: SELinux Coloring Book


  • Cat

  • Dog



  • cat_food

  • dog_food


As a policy writer, we would define that a dog has permission to eat dog_chow food and a cat has permission to eat cat_chow food. In SELinux we would write this rule in policy.

  • allow cat cat_chow:food eat;

  • allow dog dog_chow:food eat;



And processes and objects are happy.



Stopped by Kernel

SELinux Resources

  • Seriously, stop disabling SELinux.

  • Security-enhanced Linux for mere mortals - 2015 Red Hat Summit

  • SELinux NSA Mailing List

    Workshop Details

    Domain Red Hat Logo
    Student ID

Return to Workshop