{"id":587,"date":"2026-07-20T17:58:03","date_gmt":"2026-07-20T17:58:03","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=587"},"modified":"2026-08-18T22:14:50","modified_gmt":"2026-08-18T22:14:50","slug":"securing-vps-selinux-apparmor-mandatory-access-control","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/securing-vps-selinux-apparmor-mandatory-access-control\/","title":{"rendered":"AppArmor on a VPS: Profiles for nginx, MySQL, and sshd Without Locking Yourself Out"},"content":{"rendered":"\n

Every Ubuntu VPS ships with AppArmor enabled, and almost nobody looks at it until a service starts failing with cryptic permission denied<\/code> errors. AppArmor is a Mandatory Access Control (MAC) layer that restricts what programs can do even when they run as root \u2014 which makes it one of the few security controls that actually contains a compromised web app. The catch: default profiles are tuned for stock installs, and the moment you customize nginx, move a MySQL datadir, or add PAM modules to sshd, you start collecting denials. Here is the workflow that keeps your services running while the profiles still do their job.<\/p>\n\n\n\n

Step 1: See what is actually loaded<\/h2>\n\n\n\n
sudo aa-status\n# shows loaded profiles and their mode: enforce or complain<\/code><\/pre>\n\n\n\n
Profiles in enforce<\/strong> mode block denied operations. Profiles in complain<\/strong> mode only log them. On a fresh Ubuntu image, sshd<\/code> is typically in complain mode and a handful of other services ship with profiles you never asked for. Knowing which mode each profile is in is the difference between a quiet weekend and a 2 a.m. support ticket.<\/p>\n\n\n\n
Step 2: The workflow \u2014 complain, read logs, enforce<\/h2>\n\n\n\n
Never flip a profile straight to enforce after a config change. The repeatable loop is:<\/p>\n\n\n\n
sudo aa-complain \/etc\/apparmor.d\/usr.sbin.mysqld   # 1. put the profile in complain mode\nsudo systemctl restart mysql                        # 2. exercise the new config\nsudo journalctl -k --since \"10 min ago\" | grep -i apparmor   # 3. read the denials\nsudo aa-logprof                                     # 4. approve\/deny the suggested rules\nsudo aa-enforce \/etc\/apparmor.d\/usr.sbin.mysqld    # 5. only now enforce<\/code><\/pre>\n\n\n\n
Kernel denials also land in \/var\/log\/syslog<\/code> and dmesg<\/code>. A typical denial looks like:<\/p>\n\n\n\n
audit: type=1400 audit(1750000000.123:456) apparmor=\"DENIED\"\n  operation=\"open\" profile=\"\/usr\/sbin\/nginx\"\n  name=\"\/srv\/www\/index.html\" comm=\"nginx\" requested_mask=\"r\"<\/code><\/pre>\n\n\n\n
Read it left to right: which profile, which operation, which file, which access mask. That tells you exactly what rule to add.<\/p>\n\n\n\n
Case 1: nginx with custom paths<\/h2>\n\n\n\n
The stock nginx profile allows \/etc\/nginx<\/code>, \/var\/www<\/code>, \/var\/log\/nginx<\/code> and the pid file. Serve sites from \/srv\/www<\/code> or \/home\/deploy\/sites<\/code> and you will see exactly the denial above. Two ways out:<\/p>\n\n\n\n