Securing Your Server With AppArmor
If you want to secure your server using AppArmor, you have to create and modify the profiles for all the applications you use. This can easily be done using the YaST AppArmor modules or the command-line tools.
The YaST modules are more or less self-explaining, but more for mouse users.
Therefore I’ll explain the command-line tools a bit. I’ll also explain some AppArmor basics when needed.
Of course these instructions are also valid if you use your computer as a workstation
aa-unconfined
aa-unconfined prints a list of running processes and displays if these are protected by AppArmor. Processes can have 3 states:
- enforce: the process is AppArmor-protected and can only do things that are allowed in its profile
- complain: AppArmor is watching the process in learning mode, but does not protect it
- not confined: the process is not protected or watched by AppArmor
aa-genprof
aa-genprof is a tool to generate a new AppArmor profile. It watches the process in complain mode and allows you to generate the profile.
The strategy to avoid extensive logging is usually:
- run “aa-genprof /usr/bin/something” and let it running
- run “/usr/bin/something”, quit it again
- generate a basic profile with “Scan syslog for events” (a explanation of the options is in the aa-logprof section)
- run “/usr/bin/something” for a longer time and work with it
- update the profile by using “Scan syslog for events” again
- if you think the profile is complete, quit aa-genprof with “Finish”.
This puts the profile to enforce mode.
aa-logprof
aa-logprof is used to update existing profiles. Just run it without any parameter and it will read the audit.log and display events that are not allowed by the profiles. You can choose if the requested action should be allowed - or deny it if it should not be allowed.
Sometimes AppArmor will offer to include abstractions/* files as an alternative to allow specific file permissions. These abstraction profiles are available for several usecases. Using them helps to keep your profile short without a too great risk.
Regarding execution of other applications, you have several choices: inherit, profile and unconfined.
“Inherit” means that the called application uses the same profile that is used by the calling application. This is usually a wise choice if your application calls /bin/cat or /bin/bash - creating a general profile for those would be a bad idea.
“Profile” means that AppArmor generates a separate profile for this application. This is a good choice if you want separate restrictions for the called application and if you want to protect the called app regardless of who is calling it.
“Unconfined” means that the called application will run without AppArmor protection. Please think twice before choosing this 
aa-complain
aa-complain is a small tool to put an application into complain mode. Just call it with “aa-complain /usr/bin/something”.
aa-enforce
Guess what it does - correct, it puts a profile to enforce mode. And yes, you can call it with “aa-enforce /usr/bin/something”.
Test This Out Yourself
- The profiles live in /etc/apparmor.d/ and config files in /etc/apparmor/
- type apparmor_status (should be in path) to see status.
- type autodep /bin/ping — that puts ping in complain or learning mode.
- after pinging a few things by name and IP to fill the apparmor log, type logprof to go through the wizard to create the ping profile. It asks questions and generally you just hit A for accept though if its a dir you know it needs full access to you can hit G for glob.
- Once that was saved I typed enforce bin.ping and voila.
I think that’s the basics of apparmor. Great security tool.
Related Posts
Tags: , apparmor, Debian, novell, OpenSuse, Security, slackware, Ubuntu
Loading ...