AppArmor is the most effective and easy-to-use Linux application security system available on the market today. AppArmor is a security framework that proactively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing good program behavior and preventing even unknown software flaws from being exploited. AppArmor security profiles completely define what system resources individual programs can access, and with what privileges. A number of default policies are included with AppArmor, and using a combination of advanced static analysis and learning-based tools, AppArmor policies for even very complex applications can be deployed successfully in a matter of hours.
Software flaws in complex applications provide attackers with an avenue to compromise systems that host critical data in the enterprise. Firewalls and other forms of perimeter security only solve part of the problem because businesses are having to open their network to access by customers, partners and mobile employees. So, the perimeter essentially shrinks down to the machine that hosts the critical data. IT organizations struggle to keep these machines patched to protect against the latest exploits, but this reactive security strategy still leaves businesses exposed.
With experience, hackers are becoming faster at exploiting a vulnerability and sometimes a hacker may be the first to discover the vulnerability. A zero-day exploit is one that takes advantage of a security vulnerability on the same day that the vulnerability becomes generally known leaving businesses little or no time to fetch, QA and apply patches to their systems. AppArmor provides a way to lock down those systems so that software flaws, whether they are known or unknown, can't be exploited to compromise the system. And, AppArmor solves the problem of zero-day exploits by providing a proactive security model that enforces good application behavior regardless of the latest attack.
Most operating systems have a built-in security mechanism known as access control. Linux employs Discretionary Access Control (DAC) which means that a program runs with the permissions of the user executing it. Since we have seen that attackers often exploit flaws in programs that allow them to compromise systems, giving a program all the privileges of the user running the program is highly risky.
AppArmor supplements the discretionary access control mechanism of Linux with Mandatory Access Control (MAC). Under mandatory access control, each program runs with a very strict set of permissions that are specified by the system, not the user. AppArmor enforces the idea of least privilege for programs, that is, granting programs only the privileges they need to do their job and nothing else.
AppArmor achieves mandatory access control by assigning a profile per application, that is, a security policy that completely defines what system resources an application can access, and with what privileges. AppArmor profiles are human-readable text files that mediate access to files and directories as well as determine what POSIX capabilities an application is allowed to have. A typical rule within an AppArmor profile may look like this:
/etc/apache2/conf.d/apache2-manual.conf r
This particular rule gives the application read only access to the file apache2-manual.conf.
In addition to giving an application explicit read, write, or execute access to files and directories, AppArmor enables the mediation of POSIX capabilities. POSIX capabilities are a partitioning of the all powerful root privilege into a set of distinct privileges that may be individually granted to, or removed from, different processes. Capabilities allow system administrators to fine-tune what a privileged process is allowed to do, which helps to reduce security risks to their system.
Simply, AppArmor prevents attackers from exploiting software flaws to get applications to do bad things. Many security vulnerabilities result from bugs in trusted programs. A trusted program runs with privilege that some attacker would like to have, and the program fails to keep that trust if there is a bug in the program that allows the attacker to acquire that privilege. AppArmor is an application security solution designed specifically to provide least privilege confinement to suspect programs. AppArmor allows the administrator to specify the domain of activities the program can perform by developing a security profile for that application, that is, a listing of files that the program may access and the operations the program may perform. AppArmor provides sufficient security to prevent the exploitation of software vulnerabilities in Internet servers, while minimizing performance, implementation and administrative costs.
An unconfined system administrator does need to be aware that AppArmor does not provide a magic defense against security problems. Carelessly installing new applications that require special privileges without taking care to consider the security implications may result in systems with exposed security problems.
To help system administrators understand their level of exposure, we have included a system analyzer that can assist in discovering applications that may have been added to a system since AppArmor policy was generated. Future releases of AppArmor will include additional tools to help confine such unknown applications.
It is important to remember that a confined process doesn't have full privileges over the entire system. Depending on policy, system administrators, end users, and compromised daemons may not be able to install unprofiled applications.
There are several levels of tamper protection; first, only unconfined processes may load, unload, or modify the policy enforced by the kernel. Second, AppArmor policy is stored in the filesystem itself; if the system administrator feels a particular program is a risk, she can provide an AppArmor policy for the program that does not allow writing to /etc/subdomain.d/.
Novell has developed AppArmor profiles for a number of programs and daemons that ship with the SUSE Linux operating system including apache, sendmail, postfix and ssh. These profiles provide a good starting point and in most cases can be used as-is without modification. In addition, Novell is in the process of developing AppArmor profiles for Novell applications like OES and Groupwise.
The chroot facility in Linux allows you to sandbox applications by placing them in a chroot jail, along with the resources they need to perform their functions. The attacker who successfully exploits a sandboxed program gains access to only the capabilities afforded by the sandbox. While somewhat effective, sandboxing a program is hampered by the inconvenience of needing to place all resources required by that program in the sandbox. Further, as software entities, it is possible for attackers to escape chroot sandboxes that contain programs running as the root user. AppArmor provides a similar containment value, but without the need to physically move the application and its required resources into a separate container. AppArmor is essentially chroot by reference.
Version 2.1 of AppArmor shipped in openSUSE 10.3, and it resolves the paths within a chroot different than previous versions of AppArmor. In AppArmor 2.1 pathnames within a profile are no longer relative to the chroot but are a canonical path of the filesystem namespace. The means that if a chroot is done to /jail then the paths in the AppArmor profile must have /jail prepended. This also applies to profiles names, profiles that are to be attach to programs run within the chroot need the /jail prepended as well.
AppArmor can be used to create "roles" (in the RBAC sense) that operate as restricted shells in Linux. This even works on root shells. For instance, suppose you have some junior system administrators in your enterprise, and their job is to do system log analysis looking for problems. They need root access to do this, but you don't feel comfortable trusting them; they might be evil, or they might just make mistakes. So you want to allow them to only have *part* of root's privilege to access the system log, but *not* the power to mess with the Oracle database, reboot the machine, etc.
To do this, you create a role using AppArmor. You do this by:
1. Creating a "special" shell, hardlink to the shell, for the role, e.g. call it logbash for
the role of syslog analyst.
2. Create an AppArmor profile for logbash that restricts anyone
running logbash to only do the necessary operations.
3. Make logbash be the default login shell for people who will be
operating in this role.
4. Change the UID of these people to 0 so that they have root's
privilege, but use their own password and are restricted to run
logbash, so you don't have to share root's password.
AppArmor can also be combined with sudo to provide an alternative form of RBAC.
If your suduoers file grants a user access to e.g. vim, then the user can type :!<enter> and be presented with a shell. From that shell, the user has complete privileges over the entire system. The same happens with mutt, pine, less, more, and many other simple utilities. (Leave off the ':' where necessary. Add 'sh' where necessary. :)
AppArmor would allow the user to spawn a shell only if a shell was used during training. AppArmor would only allow the user to execute commands, read files, and write files, that were executed, read, or written, during training.
sudo has no control over the program once it has been exec()'d. AppArmor can control execution all the way down.
AppArmor can be combined with sudo as an alternative RBAC solution (see next question).
Combining sudo with AppArmor provides a complementary form of RBAC that can be combined with restricted login shells. When using restricted login shell the user requires a different password per role, and the either a role and its password must be shared between multiple users, or multiple versions of the role need to be setup (one per user). When combining AppArmor with sudo a single role can have multiple users, each one using their own password to access the role.
To do this, you create a role using AppArmor. You do this by:
1. Creating a "special" shell, hardlink to the shell, for the role, e.g. call it logbash for
the role of syslog analyst.
2. Create an AppArmor profile for logbash that restricts anyone
running logbash to only do the necessary operations.
3. Edit the /etc/sudoers.conf file, to setup a role, that allows the desired users to execute the
"special" shell.
4. users can enter the role by doing
> sudo logbash
For the user to be able to directly transition to other roles the "special" profile must provide a Px transition to sudo. If the user should not be able to transition directly from role to role then profile for the role should not be allowed to execute sudo.
If you wish to use AppArmor to confine sudo when using it to provide roles. The sudo profile must contain Px transitions to the all "special" shell that are setup to support different roles. The controlled mapping of user to role is handled by sudo, so a user will still only be able to access the roles he is allowed to by the sudo config file.
If this is combined with restricted login shell style of RBAC the "special" shell profile should contain a Px transition to sudo and sudo should be confined with an AppArmor profile.
AppArmor released under the terms and conditions of the GNU General Public License (GPL).
SELinux provides a similar level of protection as AppArmor, but it does so in a fashion that makes it difficult to deploy without a significant investment in time, expertise and resources. SELinux is an implementation of mandatory access controls that uses labeled security, ie, the application of a tag to each data file that identifies that file's appropriate security level. Labeled security has advantages in organizations where secrecy is paramount, that is, ensuring that only those authorized at appropriate clearance levels can view a given piece of data. The labels allow the operating system to handle data with appropriate controls, eliminating the need to store the information on multiple computers of varying security levels. Although this feature has value to organizations such as intelligence agencies whose main goal is to keep secret information secret, it introduces a significant level of complexity and has limited value to most commercial enterprises whose primary objective is data integrity, ie, preventing the corruption of data.
AppArmor's design is name-based and does not require re-labeling of the file system. AppArmor's implementation addresses the issue of data integrity and places a high value on enterprise requirements, in particular, ease of implementation and performance.
AppArmor is much easier to use than SELinux:
AppArmor does not require changes to the file system or applications:
AppArmor offers advantages in flexibility and performance:
Many Web applications are written in interpreted scripting languages such as PERL, PHP or Python. To enhance performance, many Web sites use mod_perl, mod_php and mod_python to place interpreters for these programming languages directly inside the Apache Web server. This improves performance because Apache no longer has to execute a large interpreter program to run a small script. However, this also compromises security because these Web applications run inside the Apache process using Apache's privileges. AppArmor provides a powerful capability to confine individual Web applications even though they are executed inside Apache using modules such as mod_perl, mod_php or mod_python. AppArmor allows Apache to change to a sub-profile corresponding to the name of the script about to be executed. If no specific profile for the script is found, a default profile associated with the interpreter can be used. This could, for example, increase security by confining all PHP pages to a similar profile permissive enough for all of the PHP pages to work but more restrictive than the Apache profile.
SELinux can only change process contexts when a process exec occurs. This means that PHP programs can only run under Apache policy rules. While this scenario is significantly more secure than the default situation, there are obviously issues in that PHP programs may tamper with parts of the web server for which they shouldn't, potentially impacting the security for both the web server and the PHP program.
AppArmor will work with all versions of Apache. However, if you wish to use AppArmor's sub process confinement to provide different policy for different applications running inside Apache, you will need a version of Apache compatible with mod_change_hat; the version of Apache supported is dependant on your version of AppArmor.
Older version of AppArmor only support Apache 2.0.x. Newer versions of AppArmor 2.1 (shipped with openSUSE 10.3), support Apache 2.2.x.
If Apache 2.2.x on an older version of AppArmor or Apache 1.3.x is an important part of your system, please contact us.
If you're doing a new install from SLES 9 SP3 media, insert CD1 and do the following:
The installation will now proceed and you will be prompted to supply the CDROM disks as needed.
If you're upgrading an existing install from SLES 9 SP3 media, insert CD1 and do the following::
Installation of the service pack with begin and you will be prompted to supply the CDROM disks as needed.
No. AppArmor comes with all of the software that you need to implement Linux application security. The AppArmor kernel module and enforcement mechanisms are included with Novell SUSE Linux Enterprise Server, along with a complete set of tools that can be run from the console or through the YaST graphical interface.
AppArmor can be managed through a text-based console, or through the YaST Control Center. For a graphical interface, simply start YaST and click on the AppArmor icon in the left side menu. From this control center, you can create new AppArmor profiles as well as manually edit or automatically update existing profiles. You can also enable/disable AppArmor, configure reporting and alerting, and run reports on AppArmor events. The automatic profile generation and update tools can also be run from the console.
For more information on using AppArmor, refer to the AppArmor Users Guide at http://www.novell.com/documentation/apparmor
To enable AppArmor, bring up YaST and click on the AppArmor Control Panel icon, click on configure, click the enable radio button, and click Done when you are finished. Once AppArmor is enabled, security profiles that are present in the directory /etc/subdomain.d will be enforced.
Describing the complete scope of good behavior of a particular application can be a daunting task. AppArmor eases this task by providing console-based and GUI tools that largely automate the development of application profiles. Through a combination of static analysis and learning-based tools, AppArmor profiles for even very complex applications can be developed and deployed successfully in a matter of hours.
The AppArmor Profile Wizard is a tool to automate the generation of application profiles. First, the target program's code is statically analyzed and a template profile is created. Then, the tool is placed into learning mode in which profile violations are recorded, but not enforced. As the program is run through its normal operation, a log file of events is built up that characterize the correct behavior of the program. When exercising of the program is finished, the Profile Wizard will guide the user through a series of questions regarding the observed behavior to determine what rules should be included in the profile.
In most cases, it is impossible to capture the full behavior of an application in learning mode. Yet it is possible to describe the full scope of good behavior without exercising every conceivable program path. Most applications require access to objects in a limited number of directories. While the number of discrete objects accessed by an application may be large and dependent on the usage scenario, the path names to those objects is typically bounded and well-defined. AppArmor's flexible policy language allows the use of wildcards or "globs" to grant an application access to objects that match a particular pattern. Wildcards can be used anywhere in the path name to grant access to an entire directory, an entire directory tree, or to files within a directory tree that matched the specified pattern. For instance:
| Rule | What the rule describes |
|---|---|
| /etc/apache2/conf.d/apache2-manual.conf r | grants read access to the specific file indicated in the path name |
| /etc/apache2/conf.d/*.conf r | grants read access to any file in the conf.d directory with a .conf extension |
| /etc/apache2/conf.d/* r | grants read access to any file in the conf.d directory |
| /etc/apache2/conf.d/** r | grants read access to the entire conf.d directory tree |
Thus, through the use of wildcards in AppArmor policies, it is not necessary to grant explicit access to every object that may be required for some mode of the application's execution as long as access to these objects is permitted by a more general rule.
Occasionally, an AppArmor profile will need to be modified to account for new behavior, modifications to the application or changes in the environment in which the application is used. AppArmor includes a tool to automate the supplementation of AppArmor profiles. The Profile Update utility works very much like the Profile Wizard utility except that it is designed for the ongoing improvement of AppArmor profiles rather than for initial generation. When the Profile Update utility is run, it scans the current system log for AppArmor related events and asks questions about each event, suggesting wildcards where appropriate.
The application profile will need to be updated if the modification to the application results in required access to system resources that are not allowed by the current profile. If this is the case, the profile can be updated by putting the affected profile into complain mode and exercising the application. After a sufficient period of exercise, the Profile Update Wizard can be run from YaST to capture any new accesses that should be part of the modified profile.
Individual security profiles can be placed in enforce mode or complain mode. Complain mode will log violations to the profile, but will not enforce the profile rules. To determine the state of profiles on your system, at a command prompt type cat /subdomain/profiles | less and the list of profiles will appear followed by the notation (enforce) or (complain). Individual profiles can easily be placed in complain or enforce mode by issuing the command enforce profile_name or complain profile_name at the command prompt.
This message means that the current AppArmor profile for this application is not allowing the application to do something. The REJECT message tells you which application is complaining, the name of the profile in question, and what resource the application is asking for. At this point, the system administrator should make a decision on the validity of that resource request, and if this is a valid request, he can update the profile in one of two ways: 1) manually by using a text editor or through the YaST interface (Edit AppArmor Profile), or 2) running the update wizard from YaST (Update Profiles Wizard) or from the command line (logprof program_name).
The correct solutions depends on the nature of the REJECT messages:
If the messages are being generated because policy is too stringent, you may use the Update Profile Wizard (or 'logprof' program from the command line) to interactively decide what new rights should be granted. Once the new rights have been added to the policy files, and policy reloaded, the messages will stop.
If the messages are being generated because the policy is an accurate description of what the system administrator wants enforced (but not necessarily what the program expects), there are several options:
There are three cases to describe how policy is treated when there are both local modifications and the system administrator upgrades a policy RPM, depending on the approach the policy packager has taken to creating the packaging.
Jon Warbrick has written a very nice table summarizing RPM's behaviour:
rpm -qc <package> will report which files are marked %config.
setterm -msg off
See also the /proc/sys/kernel/printk entry in the proc(5) manpage.
KDE uses a complex scheme of IO slaves and dlopen() coding to improve performance (both throughput and latency). AppArmor decides which policy to enforce for a given process based on traditional Unix style execve() calls when a new program is started. Currently, the two models do not work well together.
You can either (a) confine the entirely of the KDE applications in a single large profile (potentially suitable for Kiosk deployments) or (b) use the following environment variables to defeat KDE's shared IO slaves and clone()+dlopen() performance enhancements: KDE_EXEC_SLAVES=1 KDE_IS_PRELINKED=1
To apply these environment variables to the entire system, they need to be set before XDM/GDM/KDM or startx -- /etc/security/pam_env.conf may be a suitable choice.
AppArmor can be used with any Linux file system.
According to internal benchmarks, AppArmor overhead has been measured at around 2% using Webstone against Apache.
Effective hardening of a computer system requires minimizing the number of programs that mediate privilege and then securing the programs as much as possible. With Novell AppArmor, you need only profile the programs that are exposed to attack in your environment which drastically reduces the amount of work required to harden your computer. AppArmor profiles enforce policies to make sure that programs do what they are supposed to do, but nothing else. To effectively secure your system, you should consider creating an AppArmor profile for each privilege-mediating program such as:
A more automated method is to use the AppArmor tool unconfined. From a root prompt, type the command unconfined. The tool inspects your open ports from inside your computer (using the command netstat -nlp), detects the associated programs, inspects the set of AppArmor profiles you have loaded and reports these programs (along with their associated AppArmor profiles).
Yes. The process of profiling any application with AppArmor is the same. Use the Profile Wizard either from the command line or from YaST, and follow the instructions.
© 2009 Novell, Inc. All Rights Reserved.
