Paranoid Penguin - An Introduction to Novell AppArmor
Although AppArmor's open-source license hopefully will lead to ports on other Linux distributions, for the time being AppArmor is available only for SUSE Linux and SUSE Linux Enterprise. The rest of this article, therefore, is necessarily specific to SUSE. I'm scratching only the surface here. For detailed information on how to configure and use AppArmor, see the AppArmor Admin Guide Using Yast, whose path is /usr/share/doc/packages/subdomain-docs/ug_apparmor.pdf, provided you've installed SUSE's subdomain-docs package.
Note: prior to being acquired by Novell, AppArmor previously was called Immunix SubDomain. Many of AppArmor's filenames and package names still include the word subdomain.
AppArmor has its own YaST module, called Novell AppArmor (Figure 1). As you can see, most of the applets in this module deal with creating and managing AppArmor Profiles. Each application protected (confined) by AppArmor must have its own AppArmor profile. Profiles can be created manually or by using the Add Profile and Update Profile Wizards or with the Manually Add Profile applet.
The AppArmor control panel is used to enable and disable AppArmor and to enable, configure and disable AppArmor security event notification. Important note: any time you enable AppArmor manually, you must restart every AppArmor-protected application (simply rebooting is your safest bet). An application must start while AppArmor is already running in order to benefit from its protection. Obviously, if AppArmor is enabled at boot time, you don't need to worry about this.
Two types of applications are particularly important to protect: programs that run setuid root (that is, run with root's privileges) and network applications. AppArmor comes preconfigured with profiles for a variety of setuid-root programs and network applications, including Apache, ping, Firefox, Opera, Evolution, sshd, ld, Postfix, Squid and Ethereal.
Two Handy Commands
You can identify all the commands and dæmons on your system that are both owned by root and have their setuid bit set (that is, that run with a user ID of root no matter who actually executes them), with a single command:
find / -user root -perm -4000 -print
As with any other find / command, this takes a few minutes to complete, but the output hopefully will be a short list. In the Internet-connected era, it's very bad form indeed to set the setuid bit on any root-owned executable unless it's absolutely necessary, so modern versions of Linux distributions tend to be very sensible in this regard. Still, you may be surprised by what you find.
One more handy command, this one peculiar to AppArmor, is unconfined. When run without arguments from a command prompt, this command lists running network dæmons that are not protected by AppArmor. You must be root, and AppArmor must be enabled, for the unconfined command to work.
Figure 2 shows the ping default profiles. As you can see, it consists of #include statements that reference the contents of other profiles, access controls on POSIX capabilities (setuid, kill, sys_boot and so forth) and file access controls.
There's actually a fourth element that Web server profiles may contain—hat definitions. Figure 3 shows part of the profile for httpd2 (Apache 2). The entries at the top of the profile that begin [+] are hats. A hat is simply an embedded profile, a sub-profile, if you will. Only profiles for hat-aware applications can have hats, and even at that, you must have SUSE's libimmunix and mod-change-hat packages installed for hats to work.
The most common use of hats is for Web applications that are run without actually being part of httpd dæmons. Figure 4 shows the contents of just such a hat, corresponding to a guestbook application on my Web server. The index.php script referenced in Figure 4 mainly needs read access to some files, but it also needs to both read and write to the guestbook file itself (book.gb) and also Apache's access log (access_log).
If this seems confusing, don't worry. It's seldom necessary to create profiles (let alone hats) manually. On many systems, you won't need to create new profiles at all—periodically running the AppArmor Update Profile Wizard when things don't work as expected may suffice. This wizard scans /var/log/messages for AppArmor-generated error messages and allows you to update the corresponding AppArmor profiles accordingly (either to allow or continue to disallow the event that triggered each error). Where appropriate/applicable, Update Profile Wizard even will create new hats, again assuming you've installed the libimmunix and mod-change-hat packages.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Where's That Pesky Hidden Word?
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- diff -u: What's New in Kernel Development