Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   

AppArmor

News

Recommended Books

 Recommended Links HOW-TOs

OpenSuse documentation

 SLES Documentation

Registration

 FAQ
 

AppArmor ("Application Armor") was originally developed by  and used in Immunix Linux 1998-2003. AppArmor is a product that Novell acquired when they bought the company Immunix in May 2005.  Novell released the software under GPL and from May 2005 through September 2007 was the main developer and maintainer of the package. AppArmor was first made available in SUSE 9 as an add-on. It was enabled by default in SUSE Linux Enterprise Server 10 and in openSUSE 10.1, but the profiling tool was deliberately restricted in scope and required the purchase of a license file to become fully functional. In September 2007, Novell laid off most of the AppArmor team.  Among other flavors of Linux only Ubuntu uses AppArmor: it was packaged for Ubuntu in April of 2007.

 AppArmor allows the system administrator to associate with each program a security profile which restricts the capabilities of that program.

In addition to manually specifying profiles, AppArmor includes a learning mode, in which violations of the profile are logged, but not prevented. This log can then be turned into a profile, based on the program's typical behavior.

AppArmor is implemented using the Linux Security Modules kernel interface.

AppArmor is a better alternative to SELinux, which is difficult for administrators to set up and maintain. Unlike SELinux, which is based on applying labels to files, AppArmor works with file paths. Essentailly it provides application specific set of file attributes. 

AppArmor is less complex and easier for the average administrator to learn than SELinux. They also claim that AppArmor requires fewer modifications to work with existing systems; for example, SELinux requires a filesystem that supports extended attributes, and thus cannot provide access control for files mounted via NFS. AppArmor is file-system agnostic.

The information below is adapted from Chris Brown Linux.com Protect your applications with AppArmor (This article is excerpted from his book SUSE Linux )
AppArmor works by profiling the applications that it is protecting. A profile records the files that an application needs to access, and the capabilities it needs to exercise, during normal, "good" operation. Subsequently, a profile can be "enforced"; that is, attempts by the application to access resources not explicitly permitted by the profile are denied. Properly configured, AppArmor ensures that each profiled application is allowed to do what it is supposed to do, and nothing else.

The documentation uses the metaphor of "immunizing" the applications, but  a medical metaphor, "quarantine" might be better, or you might think of it as offering the program a large white handkerchief to sneeze into to prevent it from spreading germs.

To give you a feel for how AppArmor works, in this lab I'll use it to profile and contain a very simple C program. Whilst this example is undeniably simplistic, it does help to show how AppArmor actually works.

Here's the program that you will profile. It's called scribble, because it scribbles on files:

#include <stdio.h>

int main(int argc, char *argv[])
{
    int i;
    FILE *fd;
    for (i=1; i<argc; i++) {
        fd = fopen(argv[i], "w");
        if (fd == NULL) {
            fprintf(stderr, "fopen failed for %s\n", argv[i]);
            return 1;
        }
        fprintf(fd, "scribbled on file %s\n", argv[i]);
        fclose(fd);
    }
}

 

If you can't read C, don't worry, it doesn't really matter. The program loops over its command-line arguments, treating each as a filename. For each one, it tries to open the file for writing, writes a line of text to it, then closes the file. If it can't open the file, it prints an error message. I created the source file scribble.c in my home directory and compiled it with:

$ cc scribble.c -o scribble

Before proceeding further, you must ensure that the apparmor module is loaded into the kernel. To do this, run the following command as root:

# rcapparmor start

To build a profile for this application, you can use YaST. From YaST's main screen, select Novell AppArmor from the panel on the left, then Add Profile Wizard from the panel on the right. On the wizard's first screen, you're invited to enter the name of the application you want to profile. Since I built scribble in my home directory, I entered the name /home/chris/scribble then clicked Create. On the next screen, you're invited to "start the application to be profiled in another window and exercise its functionality now". The idea is to run the program and make it do the full range of things that it is "supposed to do". In this case, I simply ran my little program with the command:

$ ./scribble apple orange /tmp/banana

causing it to open and write to three files. As the program runs, AppArmor records each resource that is accessed in the system log, /var/log/messages. You can run the program as many times as you want to get a complete, representative profile. When you're done profiling, click the button labeled "Scan system log for AppArmor events." Now we're taken one by one through the events that AppArmor logged. For each one, AppArmor makes suggestions about what should be added to the profile. An example is shown in the figure.

Adding a rule to an AppArmor profile

AppArmor

In this figure, the program's action of writing to the file /home/chris/apple has been noted and you're offered a number of choices of what should be added to the profile to allow this. This is where you need to put your thinking cap on. One of the options is to allow access just to that one file: /home/chris/apple. Another option proposed by AppArmor is a generalization -- namely, to allow writing to a file called apple in any user's home directory (/home/*/apple). Clicking the Glob button will suggest a still broader rule to add to the profile; in this case /home/*/*. ("Glob" is short for "globbing," a slang Unix expression relating to the use of filename wildcards.) The button labeled "Glob w/Ext" will broaden the pattern using a * wildcard, but retain the filename extension. For example, /home/chris/testimage.png would be broadened to /home/chris/*.png. Obviously, you need to make your own judgment here about what makes sense for the application. Having selected an appropriate rule, click Allow to add it to the profile, or click Deny if you don't want it added to the profile. You'll need to proceed event by event through the activities that AppArmor has logged in order to complete the profile.

Once the profile is built, AppArmor will automatically begin to enforce it. If I now try to use scribble to write to a file that's within the profile, all is well, but if I try to access a file that's not in the profile, it fails:

$ ./scribble apple
$ ./scribble mango
fopen failed for mango

The restrictions imposed by AppArmor are, of course, in addition to those imposed by the underlying filesystem. For example,

$ ./scribble /etc/passwd

will fail regardless of AppArmor, because I don't have write permission on the file.

Profiling needs to be done with care. Too tight a profile means that the application can't do its job. For example, one version of AppArmor I tested shipped with a profile for the PDF viewer acroread, which, if enforced, prevented Adobe Acrobat Reader from viewing the AppArmor documentation!

How It Works

AppArmor installs a module into the Linux kernel that monitors resource usage of programs according to their profiles. A profile can be interpreted in one of two modes: enforce mode, and complain (or learning) mode. In complain mode (used by the create profile wizard), AppArmor logs a line to /var/log/audit/audit.log through the kernel logging daemon klogd for each resource that the application accesses. Here's a typical entry:

type=APPARMOR msg=audit(1144091465.305:6): PERMITTING w access to /home/chris/apple
(scribble(26781) profile /home/chris/scribble active /home/chris/scribble)

In the second stage of profile generation, the profile wizard works its way through these lines, prompting you for the rules to be added. Behind the scenes, the utility logprof does the work here. (logprof can also be used to build the profile from the command line instead of using the YaST wizard.)

In enforce mode, system calls made by the process for resources not explicitly allowed by the profile will fail (and a message will be logged to /var/log/messages).

The profiles are stored in the directory /etc/apparmor.d. They are loaded into the kernel by the program apparmor_parser. The profile for my little /home/chris/scribble application is written to the file home.chris.scribble. The profile I generated looks like this. The line numbers are for reference; they are not part of the file.

1 # Last Modified: Wed Dec  7 15:13:39 2005
2 /home/chris/scribble {
3   #include <abstractions/base>
4
5   /home/chris/orange w,
6   /home/chris/scribble r,
7   /tmp/banana w,
8 }

Line 2 (along with the matching bracket on line 8) defines the application that this profile applies to. Line 3 includes the contents of the file /etc/apparmor.d/abstractions/base. AppArmor uses a lot of #include files to factor out common sets of access requirements into separate files. For example there are #include files for access to audio devices, for authentication, and for access to name servers. The abstractions/base file referenced here is largely to do with allowing access to shared libraries. Lines 5 - 7 are the rules for this specific application.

To profile an application in complain mode, add the notation flags=(complain) to line 2 of the profile, so that it reads:

/home/chris/scribble flags=(complain) {

You can also do this from the command line using:

# complain
/etc/subdomain.d/home.chris.scribble

and you can set the profile back to enforce mode with:

# enforce
/etc/subdomain.d/home.chris.scribble

Using complain and enforce also loads the new profile into the kernel.

AppArmor refers to the type of profiling I just performed as standalone profiling. It also supports systemic profiling, which puts all the profiles into complain mode and allows you to run them over many hours or days (even across reboots) to collect as complete a profile as possible.

The range of resource requests that AppArmor can allow or deny is broader than the simple file access checks used in this example. For example, it's also capable of restricting program execution (via the exec system call).

Table 8-4. Example profile rules

Example Description
/etc/ld.so.cache r, The file can be read.
/var/run/myprog.pid rw, The file can be read and written.
/etc/apache2/* r, All files in /etc/apache2 can be read.
/srv/www/htdocs/** r, All files in (and below) htdocs can be read.
/tmp/myprog.* l, The program can create and remove links with this name.
/bin/mount ux The program can execute /bin/mount which will run unconstrained; that is, without an AppArmor profile.
/usr/bin/procmail px The program can execute procmail, which will run under constraint of its own profile.
/usr/bin/sendmail ix The program can execute sendmail, which will inherit the profile of the current program.

Earlier versions of AppArmor included rules that restricted the establishment of UDP and TCP connections. These rules have been removed from the current version of the product, but may be restored in a future version.

What About...

...deciding what to profile? AppArmor is not intended to provide protection against execution of ordinary tools run by ordinary users. You already have the classic Linux security model in place to constrain the activities of such programs. AppArmor is intended for use on servers which typically have few or no regular user accounts. Indeed, there is no way to define user-specific profiles in AppArmor, and there is no concept of a role.

AppArmor should be used to constrain programs that (quoting the user guide) "mediate privilege"; that is, programs that have access to resources that the person using the program does not have. Examples of such programs include:

Where to Learn More

For a brief but more technical overview, read the apparmor manpage. For full details of the syntax of the profile files, read the apparmor.d manpage.

There's an interesting comparison of containment technologies such as chroot, Xen, selinux, and AppArmor at http://crispincowan.com/~crispin/TUT304_final.sxi.

SUSE Linux 10.0 contains a detailed user guide for AppArmor in PDF format. Although it's thorough, it is rather labored and has a decidedly non-open-source feel; it even contains the immortal line "contact your sales representative for more information." This guide has been removed in SUSE Linux 10.1, but documentation is available by following the the links here.

 

Old News

AppArmor's Security Goals KernelTrap

From: Crispin Cowan <crispin@...>
Subject: AppArmor Security Goal
Date: Nov 8, 5:33 pm 2007

re-sent due to a typo in addressing.

AppArmor Security Goal
Crispin Cowan, PhD
MercenaryLinux.com

This document is intended to specify the security goal that AppArmor is
intended to achieve, so that users can evaluate whether AppArmor will
meet their needs, and kernel developers can evaluate whether AppArmor is
living up to its claims. This document is *not* a general purpose
explanation of how AppArmor works, nor is it an explanation for why one
might want to use AppArmor rather than some other system.

AppArmor is intended to protect systems from attackers exploiting
vulnerabilities in applications that the system hosts. The threat is
that an attacker can cause a vulnerable application to do something
unexpected and undesirable. AppArmor addresses this threat by confining
the application to access only the resources it needs to access to
execute properly, effectively imposing "least privilege" execution on
the application.

Applications have access to a number of resources including files,
interprocess communication, networking, capabilities, and execution of
other applications. The purpose of least privilege is to bound the
damage that a malicious user or code can do by removing access to all
resources that the application does not need for its intended function.
For instance, a policy for a web server might grant read only access to
most web documents, preventing an attacker who can corrupt the web
server from defacing the web pages.

An "application" is one or more related processes performing a function,
e.g. the gang of processes that constitute an Apache web server, or a
Postfix mail server. AppArmor *only* confines processes that the
AppArmor policy says it should confine, and other processes are
permitted to do anything that DAC permits. This is sometimes known as a
targeted security policy.

AppArmor does not provide a "default" policy that applies to all
processes. So to defend an entire host, you have to piece-wise confine
each process that is exposed to potential attack. For instance, to
defend a system against network attack, place AppArmor profiles around
every application that accesses the network. This limits the damage a
network attacker can do to the file system to only those files granted
by the profiles for the network-available applications. Similarly, to
defend a system against attack from the console, place AppArmor profiles
around every application that accessed the keyboard and mouse. The
system is "defended" in that the worst the attacker can do to corrupt
the system is limited to the transitive closure of what the confined
processes are allowed to access.

AppArmor currently mediates access to files, ability to use POSIX.1e
Capabilities, and coarse-grained control on network access. This is
sufficient to prevent a confined process from *directly* corrupting the
file system. It is not sufficient to prevent a confined process from
*indirectly* corrupting the system by influencing some other process to
do the dirty deed. But to do so requires a complicit process that can be
manipulated through another channel such as IPC. A "complicit" process
is either a malicious process the attacker somehow got control of, or is
a process that is actively listening to IPC of some kind and can be
corrupted via IPC.

The only IPC that AppArmor mediates is access to named sockets, FIFOs,
etc. that appear in the file system name space, a side effect of
AppArmor's file access mediation. Future versions of AppArmor will
mediate more resources, including finer grained network access controls,
and controls on various forms of IPC.

AppArmor specifies the programs to be confined and the resources they
can access in a syntax similar to how users are accustomed to accessing
those resources. So file access controls are specified using absolute
paths with respect to the name space the process is in. POSIX.1e
capabilities are specified by name. Network access controls currently
are specified by simply naming the protocol that can be used e.g. tcp,
udp, and in the future will be more general, resembling firewall rules.

Thus the AppArmor security goal should be considered piecewise from the
point of view of a single confined process: that process should only be
able to access the resources specified in its profile:

    * can only access files that are reachable in its name space by path
      names matching its profile, and only with the permitted modes:
      read, append, write, memory map, execute, and link
    * can only use the POSIX.1e capabilities listed in the profile
    * can only perform the network operations listed in the profile

Security issues that AppArmor explicitly does *not* address:

    * Processes that are not confined by AppArmor are not restricted in
      any way by AppArmor. If an unconfined process is considered an
      unacceptable threat, then confine additional applications until
      adequate security is achieved.
    * A process that is not permitted to directly access a resource can
      influence some other process that does have access to the resource
      may do so, if the "influence" is a permitted action.
    * A confined process may only access a file if it has at least one
      of the files aliases specified in its profile.  If a file alias is
      not specified in the profile then it can not be accessed by that
      path.  The creation of aliases needs to be tightly controlled in
      confined applications, hard links creation should be limited to
      provide adequate security.
    * A confined process can operate on a file descriptor passed to it
      by an unconfined process, even if it manipulates a file not in the
      confined process's profile. To block this attack, confine the
      process that passed the file descriptor.
    * Process activities not currently mediated by AppArmor are
      permitted, e.g. confined processes can perform any IPC that DAC
      permits, other than signals as mediated by CAP_KILL.
    * Manipulating AppArmor policy requires being both root privileged
      and not being confined by AppArmor, thus there is explicitly no
      capability for non-privileged users to change AppArmor policy.
    * AppArmor confines processes if they are children of a confined
      process, or if the name of the exec'd child matches the name of an
      AppArmor profile. Another process could copy a program to a
      different path name and then execute it without confinement, but
      the other process would have to have permission to do so in the
      first place. To prevent this, confine the other process and
      additional applications until adequate security is achieved.
    * Mount and namespace manipulations can be used to arbitrarily
      change the pathnames that files appear at, and thus completely
      bypass AppArmor policy. To prevent this, processes confined by
      AppArmor are currently not permitted to call mount or manipulate
      name spaces at all. A future development may provide more granular
      controls on mount and namespace manipulations.
    * AppArmor does not slice bread, cure cancer, or bring world peace.
      This list may be expanded :-)

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux    http://mercenarylinux.com/
       Itanium. Vista. GPLv3. Complexity at work
 

GTK YaST

Just a note that work on porting YaST to GTK actually began some time ago in openSUSE, and it's being shipped with 10.3. For all the dated screenshots and links to SVN see:  http://en.opensuse.org/YaST2-GTK

Novell lays off AppArmor programmers Underexposed - CNET News.com

Posted by Stephen Shankland
Two years after acquiring the company that developed the AppArmor security software for Linux, Novell has laid off team members behind the project, CNET News.com has learned.

AppArmor's founder and leader, Crispin Cowan, joined Novell in 2005 when it acquired his company, Immunix, which developed the software. But he and four others from the project lost their Novell jobs in Portland, Ore., on September 28, Cowan confirmed.

However, he plans to continue AppArmor development. He and two other laid-off AppArmor programmers, Steve Beattie and Dominic Reynolds, launched an AppArmor consulting company on Wednesday called Mercenary Linux.

"I have lots of reputation capital. I can get another job. But I care about AppArmor as a project and I want it succeed," Cowan said in an interview Thursday. However, the change was a surprise: "I'm stunned. I was getting bonuses and raises and awards up until the time I was laid off."

AppArmor, which Novell said will still be hosted on its Web site, is software that grants software only the privileges and access it needs, an approach that reduces the powers a remote attacker can get from a compromised computer. Although leading Linux seller Red Hat is backing an earlier rival technology called SELinux, Canonical is building AppArmor into its next version of Ubuntu, Gutsy Gibbon, and Mandriva has included AppArmor in its new Mandriva Linux 2008.

Novell spokesman Bruce Lowry wouldn't comment on specifics of the layoff, but said job cuts are "part of our ongoing restructuring efforts we've been talking throughout the year." Part of that effort involves "improving our product development process."

Novell will continue updating AppArmor and using and it in its Suse Linux Enterprise Server software, but the development mechanism has changed since Novell released AppArmor as open-source software in 2006. Some companies outsource programming work to India, but with active open-source software projects, there's even lower-cost options.

"An open-source AppArmor community has developed. We'll continue to partner with this community," though the company will continue to develop aspects of AppArmor, Lowry said.

Cowan was concerned that resources need to be focused directly on the project.

"Novell wants the community to pick up maintenance and development of AppArmor. But tossing it in the wind and hoping is not good enough assurance for me, so now it's my business to go find sponsors who are willing to pay for AppArmor development," Cowan said.

Mercenary Linux will write security profiles for software, though that's not a difficult task, as well as translate the software to new hardware, help to embed it in particular devices, and, potentially, revamp it for use on different operating systems, Cowan said.

But chiefly he expects Mercenary Linux to get by on smaller projects. "It's much easier to sell a small chunk of AppArmor development to somebody who needs something specific than it is to sell the whole concept," he said. "If somebody loves us and one day wants to acquire Mercenary, that's great."

 

Recommended Links

In case of broken links please try to use Google search. If you find the page please notify us about new location
Google     

Apparmor FAQ - DeveloperNet

AppArmor - openSUSE

AppArmor - Ubuntu Wiki

AppArmor - Community Ubuntu Documentation

Novell lays off AppArmor programmers Underexposed - CNET News.com

Have you guys seen this AppArmor talk? (272 meg video off of FTP)

Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: November 08, 2008