AppArmor/SELinux for Container Isolation

1. Mandatory Access Control: A Stricter Set of Rules

As a DevOps engineer, you are well-versed in Linux permissions (chmod, chown). This is a form of Discretionary Access Control (DAC), where the owner of a resource decides who can access it.

Mandatory Access Control (MAC) is fundamentally different. It's a system-wide policy, centrally managed, that dictates what subjects (like processes) can do to objects (like files, sockets, etc.). These rules are enforced by the kernel and cannot be overridden by users, not even root.

The following article from Datadog's Security Labs provides an excellent introduction to MAC and the roles of AppArmor and SELinux.

The two primary MAC systems you will encounter are:

• AppArmor: Default in Debian-based distributions like Ubuntu. It uses a path-based model, where rules are defined for specific file paths (e.g., deny write /etc/passwd).
• SELinux (Security-Enhanced Linux): Default in Red Hat-based distributions like RHEL, CentOS, and Fedora. It uses a label-based model, where every process and resource gets a security label, and policies define how labels can interact.

2. Securing Containers with AppArmor

Since many popular base images (like Ubuntu and Debian) and host systems are Debian-based, AppArmor is highly relevant for container security.

Docker's Default AppArmor Profile

The good news is that Docker doesn't run your containers without any protection. If the host kernel has AppArmor enabled, Docker automatically applies a default profile named docker-default to all new containers. This profile is designed for broad compatibility, providing baseline protection without breaking most applications.

This video from Datadog offers a great visual demonstration of this default behavior.

The docker-default profile blocks a range of sensitive operations, such as:

• Writing to files in /proc/ and /sys/ (except for specific cgroup files).
• Mounting filesystems.
• Loading kernel modules.

You can inspect the AppArmor profile of a running container with this command:

docker inspect --format='{{.AppArmorProfile}}' <container_name_or_id>

If the output is docker-default, the default profile is active. If it's empty or unconfined, no profile is being applied, which is a security risk.

Applying a Custom AppArmor Profile

While the default profile is good, true security comes from creating a custom profile tailored to your specific application. A custom profile follows the principle of least privilege, allowing only the exact operations your application needs and denying everything else.

Let's see how to create and apply a simple profile that blocks write access to the /etc directory, even for the root user.

Hands-On Activity:

1. Check AppArmor Status: First, ensure AppArmor is active on your Linux host (this will work on Ubuntu/Debian).

   sudo aa-status
   

2. Create a Custom Profile: Create a file named docker-etc-deny in /etc/apparmor.d/:

   sudo nano /etc/apparmor.d/docker-etc-deny
   

   Paste the following content into the file. This profile includes a base set of rules and adds one explicit denial.

   #include <tunables/global>
   
   profile docker-etc-deny flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
     # Deny write, link, and lock access to /etc and its subdirectories
     deny /etc/** wlk,
   
   }
   

3. Load the Profile: Use the apparmor_parser to load your new profile into the kernel.

   sudo apparmor_parser -r -W /etc/apparmor.d/docker-etc-deny
   

   The -r flag reloads the profile, and -W is recommended for generating warnings.

4. Run a Container with the Custom Profile: Now, run an interactive Ubuntu container, applying your profile with the --security-opt flag.

   docker run --rm -it --security-opt apparmor=docker-etc-deny ubuntu:22.04 bash
   

5. Test the Restriction: Inside the container, you are the root user. Try to create a file in /etc.

   # whoami
   root
   # touch /etc/testfile
   touch: cannot touch '/etc/testfile': Permission denied
   

   Success! AppArmor has blocked the root user from writing to /etc, demonstrating the power of MAC.

Using AppArmor with Docker Compose

For your multi-service applications, you can declaratively apply AppArmor profiles in your docker-compose.yml file.

The OneUptime blog provides a clear example of the syntax.

Here's how you'd integrate it into a service definition:

services:
  nginx:
    image: nginx
    security_opt:
      - apparmor:docker-nginx-hardened # Your custom profile name

3. A Brief on SELinux and Docker

If you work with RHEL, CentOS, or Fedora, you'll encounter SELinux. Its label-based approach is more granular but also more complex than AppArmor's path-based system.

With Docker, the most common and practical interaction you'll have with SELinux involves volume mounts. By default, SELinux policy prevents a container (with the container_t label) from accessing files on the host filesystem, as they typically have a different label (e.g., unconfined_u:object_r:user_home_t:s0).

To solve this, Docker allows you to append a flag to your volume mounts to automatically relabel the host files:

• -v /path/on/host:/path/in/container:z: Use a shared SELinux label. This allows the host content to be read and written by multiple containers.
• -v /path/on/host:/path/in/container:Z: Use a private SELinux label. This makes the host content accessible only to this specific container.

Example:

# Allow the container to write to a host-mounted directory by relabeling it
docker run --rm -it -v /my/app/data:/data:Z my-app-image

Understanding these flags is critical for making stateful applications work correctly on an SELinux-enabled system.

4. AppArmor vs. SELinux: A Quick Comparison

The following table summarizes the key differences, helping you know what to expect on different systems.

5. Looking Ahead: Kubernetes Integration

Your knowledge of AppArmor and SELinux is directly applicable to Kubernetes. K8s allows you to specify AppArmor profiles via annotations and SELinux options via the securityContext field in your Pod specifications. This ensures your container hardening policies are maintained when you move from local development with Docker to production orchestration with Kubernetes.

# AppArmor in Kubernetes
apiVersion: v1
kind: Pod
metadata:
  name: nginx-apparmor
  annotations:
    container.apparmor.security.beta.kubernetes.io/nginx: localhost/docker-nginx-hardened
...

# SELinux in Kubernetes
apiVersion: v1
kind: Pod
spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"
...

Conclusion

You have now learned how to add a mandatory, non-discretionary layer of security to your containers. By applying AppArmor or SELinux profiles, you can enforce strict rules on what a containerized process is allowed to do, even if it's running as root.

Key Takeaways:

• Mandatory Access Control (MAC) provides a stronger security model than Discretionary Access Control (DAC) by enforcing system-wide policies that users cannot bypass.
• AppArmor (path-based) and SELinux (label-based) are the two primary MAC systems in Linux.
• Docker applies a default profile (docker-default for AppArmor, container_t for SELinux) for baseline security.
• For maximum security, create custom profiles that grant permissions based on the principle of least privilege.
• Use --security-opt in docker run and security_opt in docker-compose.yml to apply custom profiles.
• On SELinux systems, remember the :z and :Z flags to correctly label volume mounts.

In our next lesson, we'll continue our journey of locking down the container runtime by exploring how to run containers with a read-only root filesystem, a simple yet highly effective technique to prevent runtime modifications.