As a follow up to my previous post which gave an overview of various security technologies that can help greatly fortify Linux against attacks, I decided to provide a little tutorial aimed at putting one of these technologies to practice. Specifically, I will give an overview of how to use the Mandatory Access Control system known as AppArmor. I chose AppArmor here for two reasons:
A) It is easier to configure for a novice than SELinux is.
B) It already comes preinstalled on the most popular Linux distro, Ubuntu (and Kubuntu).
As I outlined in my previous post, there are several MAC/RBAC systems available for Linux. The most popular are probably SELinux and AppArmor. Both are similar in that they are plugged directly into the kernel via the LSM framework. They differ, however, in some fundamental ways. For the sake of brevity, let's just say that SELinux is generally considered more secure, more customizable, but much harder to write policies for. This is probably why Ubuntu chose AppArmor to be included by default. The biggest difference in security between the two is that AppArmor uses path names whereas SELinux uses inodes for labeling. This means that AppArmor could potentially be bypassed if a file's name changes or if a hard link is created to that file. This can't happen with SELinux since SELinux depends on the file system itself for security hooks. AppArmor is file system agnostic.
If you want to use SELinux, then I suggest you install Fedora. That's the bottom line. Fedora is ahead of just about every other general purpose Linux distro when it comes to security. From PIE, Exec-Shield, SSP, and SELinux, Fedora has it all covered. Moreover, Fedora enables it out of the box which means you, as an end user, don't have to do anything to reap the benefits.
If you're on Ubuntu all you have to do to get started is:
This will show the status of AppArmor, and is pretty self-explanatory. Basically it will show all the profiles and if they are set to enforcing or complain mode. I will touch on what this means later.
Next, you should navigate to the AppArmor directory:
You can think of this directory as AppArmor's configuration directory and is where all of the profiles are stored. Profiles are policies written for individual applications that you wish to lock down. In AppArmor there are two "states" a profile can be in:
Enforcing: This means the profile is actively protecting the application. By default, Ubuntu already locks down the CUPS daemon for you, but you will see several other profiles listed that you can set to enforce mode at any time.
Complain: This means a profile exists but is not yet actively protecting the application. Instead, it is sort of in "debug" mode and will put "complain" messages into /var/log/messages. What this means is that if the application wants to read, write, or execute something that isn't listed in the profile, it will complain. This is how you generally create a profile.
If you want to put a profile into enforcing mode, then you:
Similarly, if you want to put a profile into complain mode, then type:
Note: After you change a profile's status, you have to restart AppArmor:
Easy enough, isn't it?
There are actually profiles prebuilt for common applications that you can install from the Ubuntu repositories. If you want to download all of them, then you can type the following into the terminal:
Furthermore, you can get even more profiles from here. Just download them into your text editor, and name them how they are named on the site. Place them, of course, into /etc/apparmor.d.
These prebuilt profiles should generally work quite well, but I suggest you place them into complain mode first because the way you use certain apps may not be the way the profile was written. Therefore, open the application in question and do everything with it that you can think of. For instance, if Transmission is the profile in question, then put it into complain mode, download some torrents to the directory of your choice, upload some torrents, use the block list, etc.. Do everything you can think of that you would normally do with Transmission. When you're finished, you can view all of the complaints Transmission (and all other apps in complain mode) threw by typing:
Again, this will scan the log files for all AppArmor complaints. It will give you an interactive menu where it will show all complaints and will allow you to accept or deny them. This is actually a simplification since you do more than accept or deny. You can also "Glob" file paths or "Inherit" permissions, etc. I strongly suggest you read the manpage for aa-logprof to understand the options. Just type:
The first thing you need to ask yourself is for what applications do I need profiles? I recommend only creating profiles for services and applications that connect to the Internet. Probably the main application you will want to lock down is Firefox, since it is probably the most at risk app on a desktop box. By using AppArmor, you can stop almost any type of Firefox bug or exploit from doing much of anything malicious (this includes Javascript or Flash exploits, etc.). Moreover, even if there was Linux malware that could infect you via Firefox and install itself to your /home directory, it would not be able to do anything not specified by the Firefox profile. Even if someone exploits a root level process, they cannot use that root privilege for doing anything not specified in the profile!
Securing anything else besides Firefox and system daemons is really overkill for a desktop box. The profiles in the repositories should cover just about every high risk application on a standard desktop box. But if for some reason you don't want to use those profiles or if you can't find a profile for a specific application, then you can easily generate a profile from scratch. All you have to do to generate a profile from scratch is use the "aa-genprof" command:
This will create a very basic profile and place it inside your /etc/apparmor.d directory. It also automatically puts it in complain mode. Thus all you have to do is begin using the application and then use the "sudo aa-logprof app" command every now and then until you get the profile to stop complaining. Once that's done, you simply put it into enforce mode.
How Do I Tweak a Profile By Hand?
I am not going to cover what a profile looks like in any great detail (if interested see the further reading section below), but it is pretty self-explanatory to anyone used to traditional Linux file permissions and file paths. For instance, you will see "r-w-x" bits and pathnames used inside the profile. It should look very familiar to most Linux veterans and you should be able to pick up on the syntax very quickly.
This is my Kopete profile:
As you can see, it's easy to understand. The lines that start with "Deny" mean that that directory is denied the permissions outlined by the "rwx" bits you see at the end. There are more bits used with AppArmor than just "rwx" so you can look at the man pages for more info on what they do.
Another example: take this line for instance:
This means Kopete has read access to /etc/kde4.
If you really want a good overview of what a profile looks like and how to tweak it by hand, then you should read this tutorial over at the Ubuntu forums. The Ubuntu Wiki also has a page dedicated to AppArmor. And of course, there are always man pages.
Edited by thiussat - 6/3/09 at 1:09pm
A) It is easier to configure for a novice than SELinux is.
B) It already comes preinstalled on the most popular Linux distro, Ubuntu (and Kubuntu).
As I outlined in my previous post, there are several MAC/RBAC systems available for Linux. The most popular are probably SELinux and AppArmor. Both are similar in that they are plugged directly into the kernel via the LSM framework. They differ, however, in some fundamental ways. For the sake of brevity, let's just say that SELinux is generally considered more secure, more customizable, but much harder to write policies for. This is probably why Ubuntu chose AppArmor to be included by default. The biggest difference in security between the two is that AppArmor uses path names whereas SELinux uses inodes for labeling. This means that AppArmor could potentially be bypassed if a file's name changes or if a hard link is created to that file. This can't happen with SELinux since SELinux depends on the file system itself for security hooks. AppArmor is file system agnostic.
If You Are Interested in SELinux
If you want to use SELinux, then I suggest you install Fedora. That's the bottom line. Fedora is ahead of just about every other general purpose Linux distro when it comes to security. From PIE, Exec-Shield, SSP, and SELinux, Fedora has it all covered. Moreover, Fedora enables it out of the box which means you, as an end user, don't have to do anything to reap the benefits.
Getting started
If you're on Ubuntu all you have to do to get started is:
Code:
sudo apparmor_status
Next, you should navigate to the AppArmor directory:
Code:
cd /etc/apparmor.d
Enforcing: This means the profile is actively protecting the application. By default, Ubuntu already locks down the CUPS daemon for you, but you will see several other profiles listed that you can set to enforce mode at any time.
Complain: This means a profile exists but is not yet actively protecting the application. Instead, it is sort of in "debug" mode and will put "complain" messages into /var/log/messages. What this means is that if the application wants to read, write, or execute something that isn't listed in the profile, it will complain. This is how you generally create a profile.
If you want to put a profile into enforcing mode, then you:
Code:
sudo enforce <application_name>
Code:
sudo complain <application_name>
Code:
sudo /etc/init.d/apparmor restart
But Where Do I Get Profiles? Can I Create My Own?
There are actually profiles prebuilt for common applications that you can install from the Ubuntu repositories. If you want to download all of them, then you can type the following into the terminal:
Code:
sudo apt-get install apparmor-profiles
Tweaking Prebuilt Profiles
These prebuilt profiles should generally work quite well, but I suggest you place them into complain mode first because the way you use certain apps may not be the way the profile was written. Therefore, open the application in question and do everything with it that you can think of. For instance, if Transmission is the profile in question, then put it into complain mode, download some torrents to the directory of your choice, upload some torrents, use the block list, etc.. Do everything you can think of that you would normally do with Transmission. When you're finished, you can view all of the complaints Transmission (and all other apps in complain mode) threw by typing:
Code:
sudo aa-logprof
Code:
man aa-logprof
But How Can I Build Profiles From Scratch?
The first thing you need to ask yourself is for what applications do I need profiles? I recommend only creating profiles for services and applications that connect to the Internet. Probably the main application you will want to lock down is Firefox, since it is probably the most at risk app on a desktop box. By using AppArmor, you can stop almost any type of Firefox bug or exploit from doing much of anything malicious (this includes Javascript or Flash exploits, etc.). Moreover, even if there was Linux malware that could infect you via Firefox and install itself to your /home directory, it would not be able to do anything not specified by the Firefox profile. Even if someone exploits a root level process, they cannot use that root privilege for doing anything not specified in the profile!
Securing anything else besides Firefox and system daemons is really overkill for a desktop box. The profiles in the repositories should cover just about every high risk application on a standard desktop box. But if for some reason you don't want to use those profiles or if you can't find a profile for a specific application, then you can easily generate a profile from scratch. All you have to do to generate a profile from scratch is use the "aa-genprof" command:
Code:
sudo aa-genprof executable
How Do I Tweak a Profile By Hand?
I am not going to cover what a profile looks like in any great detail (if interested see the further reading section below), but it is pretty self-explanatory to anyone used to traditional Linux file permissions and file paths. For instance, you will see "r-w-x" bits and pathnames used inside the profile. It should look very familiar to most Linux veterans and you should be able to pick up on the syntax very quickly.
This is my Kopete profile:
Code:
#include <tunables/global>
/usr/bin/kopete {
#include <abstractions/X>
#include <abstractions/audio>
#include <abstractions/base>
#include <abstractions/kde>
#include <abstractions/nameservice>
#include <abstractions/user-tmp>
deny @{HOME}/.bash* rw,
deny @{HOME}/.cshrc rw,
deny @{HOME}/.profile rw,
deny @{HOME}/.ssh/* rw,
deny @{HOME}/.zshrc rw,
/etc/X11/cursors/oxy-white.theme r,
/etc/default/apport r,
/etc/kde4/* r,
/etc/kde4rc r,
/etc/kderc r,
/etc/security/* r,
/etc/ssl/certs/* r,
owner /home/*/ r,
/opt/firefox/firefox.sh Px,
/usr/bin/convert rix,
/usr/bin/kde4 rix,
/usr/bin/kopete r,
/usr/bin/kopete_latexconvert.sh rix,
/usr/bin/launchpad-integration ix,
/usr/bin/xdg-open mrix,
/usr/lib/firefox*/firefox.sh Px,
/usr/lib/kde4/**.so mr,
/usr/lib/kde4/libexec/drkonqi ix,
/usr/share/emoticons/ r,
/usr/share/emoticons/** r,
/usr/share/enchant/** r,
/usr/share/kde4/** r,
/usr/share/kubuntu-default-settings/** r,
/usr/share/locale-langpack/** r,
/usr/share/myspell/** r,
owner @{HOME}/.config/** rwk,
owner @{HOME}/.kde/** rwlk,
owner @{HOME}/.local/share/mime/** r,
owner @{HOME}/.thumbnails/** rw,
owner @{HOME}/Downloads/ rw,
owner @{HOME}/Downloads/** rw,
}
Another example: take this line for instance:
Code:
/etc/kde4/* r,
Further Reading
If you really want a good overview of what a profile looks like and how to tweak it by hand, then you should read this tutorial over at the Ubuntu forums. The Ubuntu Wiki also has a page dedicated to AppArmor. And of course, there are always man pages.
Edited by thiussat - 6/3/09 at 1:09pm



