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 😉