Securing Your Server With AppArmor
Novell Cool Solutions: Feature
By Christian Boltz
Digg This -
Posted: 9 Feb 2007
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 - and you should never have a mouse attached to your server ;-)
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 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 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 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 is a small tool to put an application into complain mode. Just call it with "aa-complain /usr/bin/something".
Guess what it does ;-) - correct, it puts a profile to enforce mode. And yes, you can call it with "aa-enforce /usr/bin/something".
In my next article, I'll explain how you can easily hand-tune your profiles using vim (even if this is rarely needed).
I'll also provide a set of profiles for a full-featured mailserver (postfix with mail users in MySQL, maildrop, mailman, amavisd, ClamAV, SQLgrey, courier for pop3 and imap) and several other daemons. You could create these profiles yourself, but you'll save a lot of time if you use mine ;-)
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com