AppArmor is widely used in containers and Kubernetes. Also an important topic for the CKS certification.<\/p>\n
We’ll break it down with a practical example to help you understand how it works.<\/p>\n
What is AppArmor?<\/h2>\n
AppArmor (Application Armor) is a security feature in built into some Linux systems that controls what individual programs can and cannot do.<\/p>\n
If an application has a security flaw or is compromised by malware, AppArmor limits the damage<\/strong> it can do.<\/p>\n For example, even if a hacker exploits a vulnerability in a web server, AppArmor can prevent it from accessing sensitive system files or running harmful commands.<\/p>\n Let\u2019s say you are running an Apache web server.<\/p>\n Without AppArmor<\/strong>, if Apache is compromised, it can read any file on the system or execute random scripts, posing a serious security risk.<\/p>\n With an AppArmor profile<\/strong>, you can restrict Apache\u2019s access by:<\/p>\n At the same time, it cannot access user files in \/home\/ or run unauthorized commands.<\/p>\n You might ask, “Can\u2019t I do this using file permissions?”<\/strong><\/p>\n Here is where it differs.<\/p>\n File permissions control access based on user\/group IDs. If a user is compromised, the attacker can potentially access all the files<\/strong> owned by the user.<\/p>\n Whereas AppArmor controls access based on what a program itself is allowed to do, no matter which user is running it.<\/p>\n So even if Apache is compromised, it still can\u2019t access anything outside the allowed paths.<\/p>\n AppArmor falls under Mandatory Access Control (MAC).<\/p>\n MAC is a security model <\/strong>where access to resources (files, directories, network ports, etc.) is strictly controlled by a central policy.<\/p>\n Unlike Discretionary Access Control (DAC)<\/strong>, where the owner of a resource (e.g., a file) can set permissions (read, write, execute), MAC policies are enforced system-wide and cannot be overridden by users or programs, even if they have elevated privileges like For example, even if a program runs with root privileges, AppArmor can block it from modifying \/etc\/passwd<\/strong>. If an attacker compromises the program, they are still restricted by AppArmor.<\/p>\n AppArmor works based on profiles<\/strong>, similar to seccomp.<\/p>\n Each profile is a plain-text file that defines what a program is allowed to do.<\/p>\n On Linux systems, you can find existing AppArmor profiles in \/etc\/apparmor.d\/<\/strong><\/p>\n For example,<\/p>\n Let’s understand an AppArmor profile<\/strong> with a practical example.<\/p>\n We will create a simple Bash script that attempts to read \/etc\/shadow<\/strong> (a file that contains hashed passwords and should be protected).<\/p>\n The idea is to block<\/strong> the script from reading \/etc\/shadow<\/strong>, even when run as the root user.<\/p>\n Lets create the script.<\/p>\n If you run the script as root, you will not get any error. It will display the \/etc\/shadow contents.<\/p>\n Now, let’s create an AppArmor profile<\/strong> that prevents the script from reading \/etc\/shadow<\/strong>.<\/p>\n We will define this profile in \/etc\/apparmor.d\/root.script.sh<\/strong>.<\/p>\n Let’s load the profile.<\/p>\n Check the status.<\/p>\n It should now show the correct path ( Now lets run the script and see what happens. You should get a permission denied<\/strong> error when trying to access As you can see, AppArmor restricts applications based on profiles, even if you run them as root.<\/p>\n Why is AppArmor Restricting Root?<\/p>\n Root has full system access, but AppArmor controls<\/strong> what an application (even one run by root) can do.<\/p>\n This prevents privilege escalation attacks<\/strong> (e.g., a compromised root script can’t access sensitive files like AppArmor is integrated into container runtimes to enforce Mandatory Access Control (MAC) on container processes.<\/p>\n The runtime loads these profiles when starting a container, ensuring each container operates in a sandbox.<\/p>\n For example, Docker comes with a default profile called docker-default. This profile is applied to every container unless overridden. You can check the profile here<\/a>.<\/p>\n It is designed to<\/p>\n Here is a simple example that shows the docker default AppArmor profile blocking reading \/proc\/sysrq-trigger using cat.<\/p>\n AppArmor improves Linux security by restricting program actions, preventing exploits, and ensuring the least privilege. A must-know for system admins and CKS aspirants!<\/p>\n If you have any doubts about this blog, drop it on the comment!<\/p>\n Want to Stay Ahead in DevOps & Cloud? Join the Free Newsletter Below.<\/p>\nExample Use case<\/h2>\n
\n
Mandatory Access Control<\/h2>\n
root<\/code>.<\/p>\nHow Does AppArmor Work?<\/h2>\n
$ ls -p \/etc\/apparmor.d\/ | grep -v \/\n\nlsb_release\nnvidia_modprobe\nsbin.dhclient\nusr.bin.man\nusr.bin.tcpdump\nusr.lib.snapd.snap-confine.real\nusr.sbin.rsyslogd\n<\/code><\/pre>\nAppArmor Practical Example<\/h2>\n
$ echo -e '#!\/bin\/bash\\ncat \/etc\/shadow' > script.sh\n\n$ chmod +x script.sh<\/code><\/pre>\n$ root@ubuntu:~# .\/script.sh \n\nroot:*:19579:0:99999:7:::\ndaemon:*:19579:0:99999:7:::\n.\n.\n.<\/code><\/pre>\n#include <tunables\/global>\n\nprofile \/root\/script.sh {\n # Allow reading its own file\n \/root\/script.sh r,\n\n # Deny access to \/etc\/shadow\n deny \/etc\/shadow r,\n\n # Allow execution of Bash\n \/bin\/bash rmix,\n\n # Allow execution of 'cat' or any other needed commands\n \/usr\/bin\/cat rmix,\n}<\/code><\/pre>\nsudo apparmor_parser -r \/etc\/apparmor.d\/root.script.sh<\/code><\/pre>\n$ root@ubuntu:~# sudo apparmor_status | grep script.sh\n \n \/root\/script.sh<\/code><\/pre>\n\/root\/script.sh<\/code>)<\/p>\n\/etc\/shadow<\/code>, even as root.<\/p>\n$ root@ubuntu:~# .\/script.sh\n\n.\/script.sh: line 2: \/usr\/bin\/cat: Permission denied<\/code><\/pre>\n\/etc\/shadow<\/code>). It enforces least privilege<\/strong>, allowing only the necessary permissions.<\/p>\nAppArmor In Containers<\/h2>\n
\n
![\"\"](\"https:\/\/blog.techiescamp.com\/content\/images\/2025\/03\/image-1.png\")
<\/figure>\nConclusion<\/h2>\n
\n