Stage 3 · Build

Namespaces, cgroups & Security

LSM Policy Models

SELinux labels, AppArmor profiles, Landlock, and enforcing least privilege.

8 min readLinux Deep DivesBuild

LSM Framework

LSM (Linux Security Module) is the framework that allows security policies to be enforced at the kernel level. LSM hooks are placed at every critical kernel operation — file access, process control, network access, and more.

Check active LSM


# Check which LSM is active
cat /sys/kernel/security/lsm
# lockdown,capability,landlock,yama,apparmor,selinux

# Or check via /proc
cat /proc/self/attr/current
# unconfined  (AppArmor)
# or
# system_u:system_r:unconfined_t:s0  (SELinux)

# LSMs can be stacked (multiple active)
# Common stacks: apparmor+landlock, selinux+landlock

Multiple LSMs can be active simultaneously. Landlock is always available as a supplementary LSM for unprivileged sandboxing.

SELinux Deep Dive

SELinux type enforcement


# View security contexts
ls -Z /var/www/html/
# system_u:object_r:httpd_sys_content_t:s0 index.html

# Format: user:role:type:level
# type is the primary enforcement mechanism

# Check what a process can access
sesearch --allow -t httpd_sys_content_t /var/www/html/
# Found 1 semanticAV rules
#   allow httpd_t httpd_sys_content_t : file { getattr open read };

# Create a custom policy module
cat > myapp.te << 'EOF'
policy_module(myapp, 1.0)
require { type httpd_t; }
allow httpd_t custom_data_t:file read;
EOF

# Compile and install
checkmodule -M -m -o myapp.mod myapp.te
semodule_package -o myapp.pp -m myapp.mod
sudo semodule -i myapp.pp

SELinux type enforcement defines which process types can access which resource types. The policy is comprehensive but complex to manage.

SELinux booleans and troubleshooting


# SELinux booleans (toggleable policy switches)
getsebool -a | grep httpd
# httpd_can_network_connect --> off
# httpd_can_network_connect_db --> off
# httpd_enable_homedirs --> off

# Enable a boolean
sudo setsebool httpd_can_network_connect on

# Troubleshoot denials
sudo ausearch -m AVC -ts recent
# type=AVC msg=audit(1234567890.123:456): avc: denied { read }
# for pid=1234 comm="httpd" name="config" dev="sda1" ino=789
# scontext=system_u:system_r:httpd_t:s0
# tcontext=system_u:object_r:etc_t:s0

# Generate a policy module from denials
sudo ausearch -m AVC | audit2allow -M mypolicy
sudo semodule -i mypolicy.pp

audit2auto generates policy modules from observed denials. Use it to build custom policies based on actual application behavior.

AppArmor Deep Dive

AppArmor profile creation


# Generate a profile for a program
sudo aa-genprof /usr/sbin/nginx

# Or create manually
cat > /etc/apparmor.d/usr.sbin.nginx << 'EOF'
#include <tunables/global>

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

  # Capabilities
  capability net_bind_service,
  capability setgid,
  capability setuid,

  # Network access
  network inet stream,
  network inet6 stream,

  # File access
  /etc/nginx/** r,
  /var/log/nginx/** w,
  /var/lib/nginx/** rw,
  /run/nginx.pid rw,
  /usr/sbin/nginx mr,
  /tmp/** rw,
}
EOF

# Load the profile
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

# Set to enforce mode
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

AppArmor profiles are path-based and easier to understand than SELinux. They specify file access, network access, and capabilities explicitly.

Landlock LSM

Landlock unprivileged sandboxing


# Landlock allows unprivileged processes to restrict themselves
# Available since kernel 5.13

# Check Landlock support
cat /sys/kernel/security/lsm | grep landlock
# lockdown,capability,landlock,yama,apparmor

# Landlock is used programmatically (C code)
# It restricts filesystem access for the process and children

# Test Landlock availability
python3 -c "
import os
print('Landlock available:', os.path.exists('/sys/kernel/security/landlock'))
"

Landlock is unique because it allows unprivileged processes to sandbox themselves. Applications can restrict their own access without root or special configurations.

Selecting an LSM

LSM	Configuration	Complexity	Best For
SELinux	Labels + policies	High	RHEL, compliance-heavy
AppArmor	Path-based profiles	Medium	Ubuntu, desktop, containers
Landlock	Programmatic API	Low	Application self-sandboxing
seccomp	Syscall BPF filters	Low	Syscall restriction only
Yama	ptrace restrictions	Low	Process tracing control

Enforcing Least Privilege

Start with deny-all policies and add permissions as needed
Use AppArmor complain mode to learn application behavior
Use SELinux audit2allow to generate custom modules
Combine LSMs: Landlock + AppArmor/SELinux + seccomp
Regularly review and tighten policies
Test policies in staging before production

Start with AppArmor for new deployments

AppArmor is simpler to configure and debug than SELinux. Use complain mode to learn your application's needs, then switch to enforce mode.

Landlock is the future of application sandboxing

Landlock lets applications enforce their own access control without root privileges. As more applications adopt Landlock, system-wide LSM configuration becomes less critical.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.