AppArmor

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.

A good intro to Apparmor can be found in Ubuntu Community Forum post  Introduction to AppArmor

The document /usr/share/doc/packages/subdomain-docs/ug_apparmor.pdf , included in the subdomain-docs package, is the AppArmor User's Guide. It's not bad, althouth does not written clearly enough.

The key idea of AppArmor is to associate with each program a security profile which restricts the capabilities of that program.

If you run the YaST AppArmor Control Panel module and enable AppArmor, a default profile is loaded that includes settings for many common daemons and commands, including netstat, ping, traceroute, firefox, evolution, gaim, syslogd, acroread, ethereal, appropos, procmail, postfix (smtpd, and so on), Apache2 (httpd2-prefork), nscd, identd, ntpd, sshd and squid.

To help manually specify profiles or modify existing one, 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. Essentially it provides application specific set of file attributes or if you wish an application based umask for directories you want to protect. 

AppArmor is less complex and easier for the average administrator to learn than SELinux because idea is both transparent and very appealing: instead of static set of filesystem attributes you have a dynamic set but the behavior of it is well known and widely understood.  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.

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

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:

• Programs that run setuid or setgid (i.e., which run with the identity of the program's owner or group). You can find programs that run setuid to root with the command:

  # find / -user root -perm -4000

• Programs run as cron jobs. You can find these by ferreting around in the crontab files in directories such as /etc/cron.d, /etc/cron.daily, /etc/cron.weekly, and so on.
• Web applications; for example, CGI scripts or PHP pages invoked by a web server.
• Network applications that have open ports. AppArmor provides a little utility called unconfined that uses the output from netstat -nlp to identify programs that are currently running with open network ports, but which currently have no profile.

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.

NEWS CONTENTS

• 200102 : AppArmor more user friendly than SELinux #LinuxCon - InternetNewsThe Blog - Sean Michael Kerner ( AppArmor more user friendly than SELinux #LinuxCon - InternetNewsThe Blog - Sean Michael Kerner, )

Old News ;-)

AppArmor more user friendly than SELinux #LinuxCon - InternetNewsThe Blog - Sean Michael Kerner

AppArmor more user friendly than SELinux? #LinuxCon

By Sean Michael Kerner on August 9, 2010

From the 'Linux Security' files:

BOSTON. There are number of access control systems available for Linux but which one is easier to use?

At LinuxCon, Z. Cliffe Schreuders (pic left) a doctoral candidate at Murdoch University in Australia presented the findings of a small usability study he conducted into Linux access control systems.

Long story short, his study of 39 people found that AppArmor was generally found to be more user-friendly than SELinux. SELinux is the system used by Red Hat, while AppArmor is favoured by openSUSE and and Ubuntu.

Schreuders said that his study found that with SELinux the biggest issue is the user interface and its complexity.

On the other hand, AppArmor isn't without it's issues. Schreuders suggested that AppArmor's output and policy language both need to be clear as well. Additionally he noted that with AppArmor users have too many decisions they need to make.

The Red Hat people in the audience, didn't agree with Schreuders view and argued that users don't want to write policies in the first place. Dan Walsh from Red Hat argued that Schreuders core assumptions were wrong.

My view on this is simple, SELinux is a pain and it's not easy, though in recent releases (esp Fedora 13) it has gotten much easier to setup and maintain policy that works well.

3 Comments

Z. Cliffe Schreuders said:

Thanks for the very timely write up. The presentation definitely invoked a lively discussion. I feel it is worth mentioning that not everyone shared Dan's view. A number of other Linux security developers in the room gave good arguments for improving the usability of policy specification. Many of the SELinux folks are of the philosophy that only SELinux experts should specify policy. This is understandable given the complexity of SELinux. However, there are a number of projects which aim to improve the usability of SELinux. Improving the usability of application restrictions has the potential to enable developers to specify policy for their applications, allow users to protect themselves against malicious code, and makes life easier for anyone who chooses to configure the security systems.

August 9, 2010 9:00 PM

Toshiharu Harada said:

I felt something uncomfortable to see "the complexity of SELinux" in Cliffe's comment above. As was explained in Joshua's presentation, "in ur webserver, writin ur logs", the model of SELinux is quite simple (subject accesses object). I believe what makes people SELinux is hard to deal with comes from the fact that SELinux policy settings reflects the complexity of the Linux.

Here are from my memo of Joshua's slides:

• Linux is complicated
• 49 object classes
• hundreds of permissions
• pseudo filesystems
• devices
  • everything is a file (except what isn't)
  • device drivers all behave slightly differently

If we can agree with "Linux is complicated", then somebody has to pay for that. I mean, there can be no magic to remove the complexity. And the amount needs to be payed depends on how far we go. Obviously it is far much easier to run SMACK than SELinux, but if SMACK grows and reach the same level as SELinux (in that case, it has to be renamed), I think it will be as hard as SELinux.

I also would like to mention that Dan has pointed out that once a policy error occurs, there are no critical differences between SELinux and AppArmor (or whatever MAC implementations). When we talk about "usability" of MAC, managing error should be taken into account.

August 10, 2010 12:33 AM

Anil Wang said:

Toshiharu, complexity hinders audit-ability. The more complex a system, the harder it is to make sure that it does what you expect. That's why Unix systems which traditionally had only "3 level User, Group, Other" security tends to be far more secure and less combersome than NT's more complete ACL. Unix's security is easy to audit, NT's isn't.

While it is try that NT's ACL can be far more secure and fine grained than Unix's ACL, it is so complex that few people actually spend the time to make it so. As a result, Unix users have few problems running at restricted privileges while NT users often need to run as Power Users or even Administrator just to use their scanner.

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

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."

[Jan 12, 2006] LWN Novell releases AppArmor

Novell has announced that it has released AppArmor as free software. AppArmor was developed by Immunix (which was acquired by Novell); it is a Linux security module which can be used to precisely control what specific applications can do. It looks somewhat similar to SELinux, but simpler and less ambitious in scope. The OpenSUSE AppArmor detail page has more information, including an example configuration file.

---

(Log in to post comments) Posted Jan 12, 2006 13:29 UTC (Thu) by subscriber nix [Link]

I've been avoiding SELinux because of its sheer complexity and overdesign: I don't need labelled security, and neither does anyone else I know: filenames are perfectly adequate labels. This looks *much* more maintainable (as in `practical for a mortal human to write a set of policies'). It's very nice that there's now a demarcation between `coarse root-only security' and SELinux. (And, hey, something that uses capabilities for something near their intended purpose! Wow!)

Posted Jan 13, 2006 13:59 UTC (Fri) by subscriber davecb [Link]

I used to work on B2 Multics, and never even noticed that
they were running mandatory security. I've since lived
for some years with a Trusted Solaris 7 system, and
only the sysadmin was different. I expect SE Linux
will become as easy to use.

And, just by the way, the labels are things like
"secret" "confidential" and "unclassified", not
labels like filenames.

--dave

Posted Jan 14, 2006 0:27 UTC (Sat) by subscriber etbe [Link]

In the Unix permission scheme (IE user, group, and other having RWX bits)
the file name is NOT used for access control. If for example I use the
"mv" command to rename a file it will have the same permissions after the
rename operation. Any MAC system which does not control access based on
the Inode (as SE Linux does with XATTRs that are associated with the
Inode) will not preserve the same semantics as Unix permissions in regard
to renaming files.

Then there's the issue of hard-links. In Unix file systems a file with
hard links does not have one canonical name, each of the hard links can
be considered equally authoritative. When access is based on a regular
expression and you have two different regexes matching different hard
links to a file then you have different access granted to a file
depending on which name you use to access it.

For a comprehensive MAC system you want to be able to audit the
policy. For example to secure the /etc/shadow file we want to know which
domains can read/write it and which programs can be used to enter those
domains so that we know which programs to audit to verify that there is
no possibility of stealing or changing passwords. Such analysis is not
possible when the programs that have access to the shadow file may have
different labels depending on which name is used to access them.

A further complication of AppArmor is that file paths seem only valid
within a file system. So if /home is a separate file system then a
hostile user could request that the administrator give them an account
name which matches a regular expression for some system files. Think
about if a user had an account named "lib" or "opt"...

Posted Jan 16, 2006 11:53 UTC (Mon) by subscriber nix [Link]

Well, as I understand it AppArmor uses the filename to *look up* the inode number and then tags the inode. Obviously no other system would be secure under hardlinks, especially if as standard POSIX semantics demand any user can hardlink files owned by other users into directories they control. (I think it reasonable to assume that any system designed by Crispin Cowan wouldn't have a design flaw as large as you imply in it!)

Obviously the AppArmor globbing/regexing thing is something which should be used with care: don't put wildcards at the front of the name!

What might really cause problems for AppArmor, and for any filename-based system, is wide use of filesystem namespaces. If /etc/shadow refers to a different file depending on the PID, what do you do?

(Mind you, this screws up conventional Unix security as well. I think that no matter what you do to the filesystem namespace, / and /etc had better remain non-writable by anyone but root.)

Posted Jan 17, 2006 2:43 UTC (Tue) by subscriber etbe [Link]

With SE Linux there are access controls to determine which processes can create a hard link to a file. For example with the strict policy most processes on the system are not permitted to create hard links to files
in /etc. I believe that some of the Common Criteria certifications require that the system label Inodes not file names so any system that doesn't do something similar to what SE Linux does will not do well in
certification.

In a conventional Unix system there is nothing preventing you from having a /etc/shadow file in a chroot environment with different permissions to the "real" one.

A bigger problem for AppArmor is the fact that file specs are relative to the root of a file system. So /etc/shadow is equivalent to /home/etc/shadow if /home is a separate file system.

[Feb 24, 2006] Security wars Novell SELinux killer rattles Red Hat

Novell Inc. of Provo, Utah, has released the source code for its recently acquired open-source Linux security application, AppArmor, and has also set up a project site in hopes of attracting outside developers to further refine the program.

The release of the software has sparked debate in the open-source community, however.

Novell stressed that AppArmor is easier to use than another open-source program called SELinux. First developed by the National Security Agency, SELinux tackles the same job of mandatory access control (MAC) with an unrelenting thoroughness, though it has a reputation for being difficult to manage. "There needs to be a better way to deploy [MAC] so that the average systems administrator doesn't need to go through three weeks of training," said Frank Rego, products manager for Novell.

Some observers fear that the AppArmor project will fracture the open-source development community around the demanding science of MAC.

"In my opinion, Novell wants to split the market," said Dan Walsh, the principal software engineer of Red Hat Inc. of Raleigh, N.C. Both Red Hat and Novell offer enterprise class Linux distributions. "Rather than working with the open-source community [on SELinux], Novell has thrown out its own competing version."

Novell acquired AppArmor last May when it purchased Immunix Inc., which developed the software. Novell has made the application, along with its source code, freely available on the site under the GNU Public License. The chief component of AppArmor is a module that must be added into the Linux kernel. Those who don't want to recompile the kernel can install SUSE Linux 10 desktop Linux distribution, as well as SUSE Linux Enterprise Server 9 Service Pack 3, both of which have AppArmor preinstalled. (An AppArmor module for Slackware Linux is also in the works).

MAC software tackles the growing problem of applications executing malicious tasks on their host systems. Many of today's security problems come from application vulnerabilities that are exploited by malicious hackers or rogue programs.

MAC software keeps profiles of routine actions that each application on a computer usually takes during normal operations. When a program starts behaving in an unusual fashion, the MAC software can call on the operating system to halt that errant operation.

Although both AppArmor and SELinux use the Linux Security Module Interface-a new Linux feature allowing kernel level mediation of security issues-the programs differ in scope.

"The biggest difference between AppArmor and SELinux is in the ease of deployment," Rego said. NSA designed SELinux to address highly classified documents for sensitive environments, according to Rego. And while it executes this job well, it may be too powerful for most everyday deployments. In fact, SELinux's complexity may have been an obstacle to wider deployment, Rego speculated. Administrators may turn off security privileges in effort to facilitate smooth operations.

AppArmor has a graphical user interface that should ease deployment, Novell hopes. The package includes profiles for widely used programs and utilities, such as Apache, Sendmail, Bind and others. In addition to these programs, the administrator can also build profiles for in-house or other programs using AppArmor's characterization and behavior-learning tools.

Not everyone welcomes with the release of AppArmor.

"Is this the beginning of the Unix wars all over again?" Walsh asked on a Live Journal blog he opened to express his views on the subject.

In the early 1990s and late 1980s, different Unix vendors developed tools and applications that would only work with their own versions of Unix, later forcing them to expend considerable effort on cross-platform versions of these programs. As a result, Microsoft Corp. was able to gain significant market share by offering a single platform, with Windows NT, that could work across a wide variety of hardware.

By introducing a second MAC application into the open-source landscape, Novell is splintering the development community, Walsh charged. Only a limited number of developers have the expertise to work on such an application, and the effort Novell itself will put into AppArmor could have been applied to improving the user interface of SELinux.

"In the open-source world, we should be working together on a single product for people to use mandatory access control," Walsh said. Red Hat deploys SELinux for its own distribution, as do several other Linux distributions.

On the blog, Walsh also cast aspersions on the viability of AppArmor itself, pointing out that the program is easier to use because it doesn't control as many low-level aspects of system operation as SELinux does-aspects that are necessary to consider when setting up a secure environment.

"SELinux can be difficult to use because security is difficult to understand," Walsh said.

Download Immunix Linux 7.0 for Linux - Immunix Linux is a Red Hat 7.0-based distribution. - Softpedia

Immunix is the leading provider of enterprise class, host intrusion prevention solutions (HIPS) for Linux.

Immunix products use technology originally developed in conjunction with the Defense Advanced Research Projects Agency (DARPA) to protect systems from both known and unknown attacks, without the need for signature updates.

Here are some key features of "Immunix Linux":

· Protect business critical Linux-based applications and services
· Ensure system security and data integrity
· Comply with internal security policies and government regulations

Strengthen Your Defenses

Immunix AppArmor is strong host security that minimizes downtime and costs associated with computer attacks by protecting the applications and operating system. Flexible and easy to use, AppArmor protects server, Web-based and custom applications from malicious behavior by identifying violations to a pre-defined usage policy and enforcing correct behavior. AppArmor protected Linux systems are inherently more secure and reliable, reducing the high operational costs associated with enterprise deployments and maintaining application integrity.

Quickly Deployed and Easily Managed

The powerful features in AppArmor allow administrators to create per-program usage profiles through an automated process. AppArmor creates a template profile just by analyzing the program's code. Then, in the normal course of application testing, the Leaning Mode Tool captures "good behavior" to further define the program's profile. Once the analysis has been completed, the profile can be deployed across multiple systems, effectively locking down the application to prevent exploitation.

Simple to Manage Profile Creation

AppArmor's wizard-based graphical interface automates profile development, making it easy and straightforward to lock down Linux applications - especially for novice users - while allowing power users the flexibility they need to create finely tuned profiles via the command line tools.

Security Event Reporting

AppArmor includes multi-tier reporting with data aggregation, incident analysis, event severity and notification status via the YaST UI or HTML format.

· Executive Summary Report provides consolidated security event analysis of each host
· Host Application Report identifies the applications running on a host, as well as applications protected by AppArmor
· Security Incident Report detail on each event with technical analysis and severity prioritization

Pre-Built Profiles

Profiles can be created for all network facing applications in a relatively short period of time. AppArmor provides more than 30 pre-built profiles for popular operating system services and common applications, including:

· Apache web server with confinement for CGI scripts
· Postfix mail server
· Sendmail mail server
· MySQL relational database
· FTP server
· Samba file & print server
· NFS file server
· DNS server
· DHCP server
· OpenSSH with privilege separation before authentication
· Squid web caching proxy

Administrators can easily modify these pre-defined profiles for highly customized environments.

Integrated into the Linux Security Modules (LSM)

The Linux Security Modules (LSM) interface provides a lightweight, general purpose framework for access control. Fully integrated into the LSM, AppArmor profiles specify the files that a program may read, write and execute, using intuitive UNIX regular expressions and mode bits. Blending seamlessly with native Linux access control methods, Immunix prevents the exploitation of known and unknown vulnerabilities prior to exploitation without impacting the performance of the system it's trying to protect.

YaST-Based User Interface

Immunix AppArmor can be accessed through a YaST-based user interface, which extends the YaST management tool currently shipped with SUSE LINUX. This wizard-based graphical interface automates profile development, making it an easy and straightforward task for novice users, while giving power users the flexibility they need to create finely-tuned profiles.

Novell YES Certification

The Novell YES Certification validates Immunix&#65533;s host intrusion prevention product as a tested and proven application security solution for the Novell SUSE Linux deployments. By combining an effective host-based intrusion prevention product with Novell&#65533;s Linux platform strategy, Immunix provides organizations with a comprehensive solution that ensures business continuity and superior data protection for critical SUSE Linux deployments.

Novell SUSE Linux Enterprise Server

"Intrusion-prevention systems may be the protection companies are looking for. Unlike conventional antivirus, firewall, and intrusion-detection systems, these proactive tools are designed to protect vulnerable computers and thwart unforeseen attack methods."
-"Get Your Shields Up!", InformationWeek, October 11, 2004

Product Overview

Novell^® AppArmor, powered by Immunix^TM , is one of the most effective and easy-to-use Linux application security systems available today . It is an intrusion-prevention system that helps protect your Linux operating system and applications from the effects of attacks, viruses and malicious applications. As a result, your business can help minimize threats, protect corporate data, reduce network-administration costs and comply with government privacy and security regulations.

When you combine Novell AppArmor with SUSE^TM Linux Enterprise Server 9 from Novell, which has earned the industry's highest level of Linux security accreditation, your systems gain another layer of security. Novell AppArmor is simple to install, and it automatically plugs into the Linux Security Module (LSM) interface in the SUSE Linux Enterprise Server 9 kernel. A typical Novell AppArmor installation on SUSE Linux Enterprise Server 9 takes only a few minutes, and the result is easy configuration and enforcement across Linux servers on the network.

With Novell AppArmor, you don't need additional IT resources to keep systems secure because the product includes predefined security policies for Web, e-mail, remote login and other popular applications. It also offers wizards that make it easy to create and deploy custom security policies. And, because AppArmor provides proactive security, helping protect against even "zero-day" attacks, you can be confident that your critical business assets are protected-without the stress and expense of patching emergencies.

Application security for Linux

Novell AppArmor helps protect your Linux operating system, services and applications against internal and external threats, as well as unknown software vulnerabilities. With AppArmor, you can deploy a per-server security policy in phases, at your own pace.

Highly flexible, AppArmor can deliver security confinement for large, complex applications or for small, individual scripts. Moreover, AppArmor supports large-scale deployments-with deep kernel-level security per application-with minimal performance overhead. Once you deploy an "armored" application in your production environment, it is constrained by its security profile. Any attempt to misuse the application or access system resources outside the bounds of the profile will be considered a violation of policy and actively blocked.

More than a dozen prebuilt profiles are delivered with AppArmor to help provide protection for popular operating-system services and common applications, including Web, e-mail and remote-login applications. You can easily modify these profiles for your particular environment.

IT productivity

Because vulnerable software is the culprit in most network attacks, organizations spend considerable time and resources trying to keep their servers up to date with patches. However, frenzied patching is rarely a sound approach; there isn't always time to test patches, and they might interfere with other software on the network.

The proactive security features in Novell AppArmor can help reduce urgent system patching by stopping an attack before it impacts your system. Patching becomes a scheduled maintenance activity instead of an emergency. The result? Great IT productivity.

Auditable compliance with regulations

As a credible organization, you must comply with government and industry regulations. Not only does Novell AppArmor help protect your applications, but it also provides auditable security and reporting. You'll be able to precisely define the scope of any application and prove that it is secure.

Low cost of ownership

Novell AppArmor is an enterprise Linux application-security solution that can be applied in hours-not days-and maintained cost-effectively without requiring high levels of Linux or security expertise.

With Novell AppArmor, you can plan system updates instead of just reacting to them. You'll also find better ways to measure and report compliance. Best of all, your system can be protected against external and internal attacks, viruses and malicious applications, letting you minimize threats, protect key corporate data and helping to reduce network administration costs.

Immunix - Wikipedia, the free encyclopedia

Immunix was a commercial distribution of GNU/Linux that provided host-based application security solutions. The last release of Immunix's GNU/Linux distribution was version 7.3 on November 27, 2003. Immunix, Inc. was the creator of AppArmor, an application security system.

On May 10, 2005, Novell acquired Immunix, Inc., a long-time partner with Novell. AppArmor was one of Novell's primary interests, and as a result, it was adopted by the company and renamed Novell AppArmor powered by Immunix.

Neohapsis Archives - Immunix-Stackguard - #0001 - [Immunix-announce] Immunix AppArmor Goes Open Source

Today Novell has announced the opensourcing of the AppArmor product. Immunix users will know this as the product formerly known as SubDomain :) and a core component of the Immunix operating system. Since Immunix OS 7 plus this product has seen numerous enhancements and new features.

We will be continuing to develop this product with the community and encourage those who are interested in helping or following the development to subscribe to [email protected].

There are two locations for information about the project:

http://www.opensuse.org/apparmor

For information about AppArmor: design philosophy, user documentation,
and packages integrated as part of the openSUSE distribution

http://forge.novell.com/modules/xfmod/project/?apparmor

The Novell Forge AppArmor page. Contains links to the mail lists along
with development versions of the AppArmor code.

We sincerely appreciate your interest and support with the Immunix
products over the years and we hope that you will continue with us in
the future as part of SUSE and Novell.

With the opening of this community effort we have decided to close this
mail list effective January 11th, 2006.

Take care and thanks,

Crispin, for the Immunix/AppArmor team

--
Crispin Cowan, Ph.D.
http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com

Recommended Links

Softpanorama Recommended

Top articles

Sites

Apparmor FAQ - DeveloperNet

search

Using AppArmor to Create Confined Root Shells

Linux.com Firewall your applications with AppArmor

AppArmor - openSUSE

AppArmor - Ubuntu Wiki

Novell lays off AppArmor programmers Underexposed - CNET News.com

Presentations

Crispin Cowan (the AppArmor project lead) gave an interesting talk at FOSDEM 2006: http://ftp.heanet.ie/mirrors/fosdem-video/2006/FOSDEM2006-apparmor.avi (271 MB)

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019