Login

Use udica to build SELinux policy for containers

<div>While modern IT environments move towards Linux containers, the need to secure these environments is as relevant as ever. Containers are a process isolation technology. While containers can be a defense mechanism, they only excel when combined with SELinux.
Fedora SELinux engineering built a new standalone tool, udica, to generate SELinux policy profiles for containers by automatically inspecting them. This article focuses on why udica is needed in the container world, and how it makes SELinux and containers work better together. You’ll find examples of SELinux separation for containers that let you avoid turning protection off because the generic SELinux type container_t is too tight. With udica you can easily customize the policy with limited SELinux policy writing skills. 
 
<h2>SELinux technology</h2>
SELinux is a security technology that brings proactive security to Linux systems. It’s a labeling system that assigns a label to all subjects (processes and users) and objects (files, directories, sockets, etc.). These labels are then used in a security policy that controls access throughout the system. It’s important to mention that what’s not allowed in an SELinux security policy is denied by default. The policy rules are enforced by the kernel. This security technology has been in use on Fedora for several years. A real example of such a rule is:
<pre class="wp-block-preformatted">allow httpd_t httpd_log_t: file { append create getattr ioctl lock open read setattr };</pre>
The rule allows any process labeled as httpd_t to create, append, read and lock files labeled as httpd_log_t. Using the ps command, you can list all processes with their labels:
<pre class="wp-block-preformatted">$ ps -efZ | grep httpd system_u:system_r:httpd_t:s0 root 13911 1 0 Apr14 ? 00:05:14 /usr/sbin/httpd -DFOREGROUND ...</pre>
To see which objects are labeled as httpd_log_t, use semanage:
<pre class="wp-block-preformatted"># semanage fcontext -l | grep httpd_log_t /var/log/httpd(/.)? all files system_u:object_r:httpd_log_t:s0 /var/log/nginx(/.)? all files system_u:object_r:httpd_log_t:s0 ...</pre>
The SELinux security policy for Fedora is shipped in the selinux-policyRPM package.
<h2>SELinux vs. containers</h2>
In Fedora, the container-selinux RPM package provides a generic SELinux policy for all containers started by engines like podman or docker. Its main purposes are to protect the host system against a container process, and to separate containers from each other. For instance, containers confined by SELinux with the process type container_t can only read/execute files in /usr and write to container_file_t files type on host file system. To prevent attacks by containers on each other, Multi-Category Security (MCS) is used. 
Using only one generic policy for containers is problematic, because of the huge variety of container usage. On one hand, the default container type (container_t) is often too strict. For example:
<ul>
<li><a href="https://silverblue.fedoraproject.org">Fedora SilverBlue</a> needs containers to read/write a user’s home directory</li>
<li><a href="https://www.fluentd.org">Fluentd</a> project needs containers to be able to read logs in the /var/log directory</li>
</ul>
On the other hand, the default container type could be too loose for certain use cases:
<ul>
<li>It has no SELinux network controls — all container processes can bind to any network port</li>
<li>It has no SELinux control on <a href="http://man7.org/linux/man-pages/man7/capabilities.7.html">Linux capabilities</a> — all container processes can use all capabilities</li>
</ul>
There is one solution to handle both use cases: write a custom SELinux security policy for the container. This can be tricky, because SELinux expertise is required. For this purpose, the udica tool was created. 
<h2>Introducing udica</h2>
Udica generates SELinux security profiles for containers. Its concept is based on the “block inheritance” feature inside the <a href="https://en.wikipedia.org/wiki/Common_Intermediate_Language">common intermediate language</a> (CIL) supported by SELinux userspace. The tool creates a policy that combines:
<ul>
<li>Rules inherited from specified CIL blocks (templates), and </li>
<li>Rules discovered by inspection of container JSON file, which contains mountpoints and ports definitions</li>
</ul>
You can load the final policy immediately, or move it to another system to load into the kernel. Here’s an example, using a container that:
<ul>
<li>Mounts /home as read only</li>
<li>Mounts /var/spool as read/write</li>
<li>Exposes port tcp/21</li>
</ul>
The container starts with this command:
<pre class="wp-block-preformatted"># podman run -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it fedora bash</pre>
The default container type (container_t) doesn’t allow any of these three actions. To prove it, you could use the sesearch tool to query that the allow rules are present on system:
<pre class="wp-block-preformatted"># sesearch -A -s container_t -t home_root_t -c dir -p read </pre>
There’s no allow rule present that lets a process labeled as container_t access a directory labeled home_root_t (like the /home directory). The same situation occurs with /var/spool, which is labeled var_spool_t:
<pre class="wp-block-preformatted"># sesearch -A -s container_t -t var_spool_t -c dir -p read </pre>
On the other hand, the default policy completely allows network access.
<pre class="wp-block-preformatted"># sesearch -A -s container_t -t port_type -c tcp_socket allow container_net_domain port_type:tcp_socket { name_bind name_connect recv_msg send_msg }; allow sandbox_net_domain port_type:tcp_socket { name_bind name_connect recv_msg send_msg };</pre>
<h2>Securing the container</h2>
It would be great to restrict this access and allow the container to bind just on TCP port 21 or with the same label. Imagine you find an example container using podman ps whose ID is 37a3635afb8f:
<pre class="wp-block-preformatted"># podman ps -q 37a3635afb8f</pre>
You can now inspect the container and pass the inspection file to the udica tool. The name for the new policy is my_container.
<pre class="wp-block-preformatted"># podman inspect 37a3635afb8f > container.json # udica -j container.json my_container Policy my_container with container id 37a3635afb8f created! Please load these modules using: # semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil} Restart the container with: "--security-opt label=type:my_container.process" parameter</pre>
That’s it! You just created a custom SELinux security policy for the example container. Now you can load this policy into the kernel and make it active. The udica output above even tells you the command to use:
<pre class="wp-block-preformatted"># semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil} </pre>
Now you must restart the container to allow the container engine to use the new custom policy:
<pre class="wp-block-preformatted"># podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it fedora bash</pre>
The example container is now running in the newly created my_container.process SELinux process type:
<pre class="wp-block-preformatted"># ps -efZ | grep my_container.process unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 root 2275 434 1 13:49 pts/1 00:00:00 podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it fedora bash system_u:system_r:my_container.process:s0:c270,c963 root 2317 2305 0 13:49 pts/0 00:00:00 bash</pre>
<h2>Seeing the results</h2>
The command sesearch now shows allow rules for accessing /home and /var/spool:
<pre class="wp-block-preformatted"># sesearch -A -s my_container.process -t home_root_t -c dir -p read allow my_container.process home_root_t:dir { getattr ioctl lock open read search }; # sesearch -A -s my_container.process -t var_spool_t -c dir -p read allow my_container.process var_spool_t:dir { add_name getattr ioctl lock open read remove_name search write }</pre>
The new custom SELinux policy also allows my_container.process to bind only to TCP/UDP ports labeled the same as TCP port 21:
<pre class="wp-block-preformatted"># semanage port -l | grep 21 | grep ftp ftp_port_t tcp 21, 989, 990 # sesearch -A -s my_container.process -c tcp_socket -p name_bind allow my_container.process ftp_port_t:tcp_socket name_bind;</pre>
<h2>Conclusion</h2>
The udica tool helps you create SELinux policies for containers based on an inspection file without any SELinux expertise required. Now you can increase the security of containerized environments. Sources are available on <a href="https://github.com/containers/udica">GitHub</a>, and an RPM package is available in Fedora repositories for Fedora 28 and later.
<hr class="wp-block-separator" />
Photo by <a href="https://unsplash.com/photos/KVG-XMOs6tw?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Samuel Zeller</a> on <a href="https://unsplash.com/search/photos/lockers?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash.</a>
</div>

xSicKxBot