LSMs, AppArmor & SELinux

Mandatory Access Control — the last line of container defense

Linux Security Modules (LSM) Framework

DAC vs. MAC

Major LSM Implementations

AppArmor

AppArmor uses path-based profiles — each program has a profile that defines exactly which files, capabilities, and network operations it can use. If a program tries something not in its profile, the access is denied.

Profile Modes

aa-enforce /etc/apparmor.d/usr.sbin.nginx

aa-complain /etc/apparmor.d/usr.sbin.nginx

What Profiles Define

# /etc/apparmor.d/usr.sbin.nginx

#include <tunables/global>

/usr/sbin/nginx {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  ## File access rules
  /etc/nginx/**                r,     # read config files
  /var/log/nginx/**             rw,    # read/write logs
  /var/www/html/**              r,     # read web content
  /run/nginx.pid               rw,    # PID file
  /usr/sbin/nginx              mr,    # read + mmap self

  ## Capability rules
  capability net_bind_service,         # bind port 80/443
  capability setuid,                   # drop privileges after start
  capability setgid,
  capability dac_override,

  ## Network rules
  network inet stream,                 # TCP over IPv4
  network inet6 stream,                # TCP over IPv6

  ## Deny everything else implicitly
  deny /proc/sysrq-trigger  rwklx,   # explicit deny + log
  deny /proc/kcore          rwklx,
}

Docker's docker-default AppArmor Profile

When Docker runs on a system with AppArmor enabled (Ubuntu, Debian), it automatically applies the docker-default profile to every container. This profile:

Overriding AppArmor in Docker and Kubernetes

# Disable AppArmor for a container
docker run \
  --security-opt apparmor=unconfined \
  nginx

# Use a custom profile
docker run \
  --security-opt apparmor=my-custom-profile \
  nginx

# Load a profile first
apparmor_parser -r -W /etc/apparmor.d/my-custom-profile

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  annotations:
    # Per-container annotation
    container.apparmor.security
     .beta.kubernetes.io/web:
      localhost/my-custom-profile
spec:
  containers:
  - name: web
    image: nginx

SELinux

SELinux uses a label-based approach. Every process, file, port, and socket gets a security label. Policies define which label interactions are permitted.

SELinux Labels

How SELinux Protects Containers

1. Type Enforcement (TE) — Container processes run as container_t. SELinux policy defines what container_t can access: container files (container_file_t), container ports, etc. It cannot access etc_t, var_log_t, or other host file types.
2. Multi-Category Security (MCS) — Each container gets unique category labels (e.g., c1,c2 vs. c3,c4). Even though both containers are container_t, they cannot access each other's files because the categories don't match.
3. Separation — Container A (s0:c1,c2) cannot read files labeled s0:c3,c4 (Container B). The kernel checks categories at every file access, even for root.

SELinux in Docker

# Disable SELinux for a container (not recommended)
docker run --security-opt label=disable nginx

# Set a custom SELinux label
docker run --security-opt label=type:custom_t nginx

# Check container labels
ps -eZ | grep container
system_u:system_r:container_t:s0:c100,c200  12345 ?  00:00:01 nginx

# Check file labels
ls -Z /var/lib/docker/volumes/
system_u:object_r:container_file_t:s0:c100,c200  my_volume

Defense in Depth — The Container Security Boundary

No single mechanism provides container security. The boundary is built from multiple overlapping layers, each catching what others miss:

Container Security Layers — Summary

How the Layers Interact

1. Process calls syscall

   e.g., open("/etc/shadow")

2. Seccomp check

   Is open() allowed at all?

3. Capability check

   Does process have CAP_DAC_OVERRIDE?

4. DAC check

   Unix file permissions

5. LSM check

   AppArmor/SELinux policy allows?

Terminal — Checking Active LSM

    $ cat /sys/kernel/security/lsm

    lockdown,capability,landlock,yama,apparmor
  

    $ # Check AppArmor status

    $ aa-status

    apparmor module is loaded.

54 profiles are loaded.

42 profiles are in enforce mode.

   docker-default

   /usr/sbin/nginx

   ...

12 profiles are in complain mode.

3 processes have profiles defined.

3 processes are in enforce mode.
  

    $ # Check SELinux status (on RHEL/CentOS)

    $ getenforce

    Enforcing


    $ sestatus

    SELinux status:                 enabled

SELinuxfs mount:                /sys/fs/selinux

SELinux root directory:         /etc/selinux

Loaded policy name:             targeted

Current mode:                   enforcing

Mode from config file:          enforcing

Policy MLS status:              enabled

Policy deny_unknown status:     allowed

Memory protection checking:     actual (secure)

Max kernel policy version:      33