Novell APPARMOR 2.0.1 ADMINISTRATION GUIDE
Novell AppArmor
www.novell.com2.0.1
November29,2006 Novell AppArmor Administration Guide
Novell AppArmor Administration Guide
Copyright © 2006 Novell, Inc.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Section being this copyright notice and license. A copy of the license is included in the section entitled “GNU Free Documentation License”.
Novell, the Novell logo, the N logo, openSUSE, SUSE, and the SUSE “geeko” logo are registered
trademarks of Novell, Inc. in the United States and other countries. * Linux is a registered trademark
of Linus Torvalds. All other third party trademarks are the property of their respective owners.
All information found in this book has been compiled with utmost attention to detail. However, this
does not guarantee complete accuracy.Neither Novell, Inc., SUSE LINUX Products GmbH, the authors,
nor the translators shall be held liable for possible errors or the consequences thereof.
Contents
About This Guide v
1 Immunizing Programs 9
1.1 Introducing the AppArmor Framework . . . . . . . . . . . . . . . . 10
1.2 Determining Programs to Immunize . . . . . . . . . . . . . . . . . 12
1.3 Immunizing Cron Jobs . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Immunizing Network Applications . . . . . . . . . . . . . . . . . . 13
2 Prole Components and Syntax 19
2.1 Breaking a Novell AppArmor Prole into Its Parts . . . . . . . . . . . 19
2.2 #include Statements . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Capability Entries (POSIX.1e) . . . . . . . . . . . . . . . . . . . . 22
3 Building and Managing Proles With YaST 23
3.1 Adding a Prole Using the Wizard . . . . . . . . . . . . . . . . . . 25
3.2 Manually Adding a Prole . . . . . . . . . . . . . . . . . . . . . 32
3.3 Editing Proles . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Deleting a Prole . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Updating Proles from Log Entries . . . . . . . . . . . . . . . . . . 39
3.6 Managing Novell AppArmor and Security Event Status . . . . . . . . . 40
4 Building Proles via the Command Line 45
4.1 Checking the AppArmor Module Status . . . . . . . . . . . . . . . 45
4.2 Building Novell AppArmor Proles . . . . . . . . . . . . . . . . . . 47
4.3 Adding or Creating a Novell AppArmor Prole . . . . . . . . . . . . 48
4.4 Editing a Novell AppArmor Prole . . . . . . . . . . . . . . . . . . 48
4.5 Deleting a Novell AppArmor Prole . . . . . . . . . . . . . . . . . 48
4.6 Two Methods of Proling . . . . . . . . . . . . . . . . . . . . . . 49
4.7 Pathnames and Globbing . . . . . . . . . . . . . . . . . . . . . . 68
4.8 File Permission Access Modes . . . . . . . . . . . . . . . . . . . . 69
4.9 Important Filenames and Directories . . . . . . . . . . . . . . . . . 73
5 Proling Your Web Applications Using ChangeHat 75
5.1 Apache ChangeHat . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2 Conguring Apache for mod_apparmor . . . . . . . . . . . . . . . 83
6 Managing Proled Applications 87
6.1 Monitoring Your Secured Applications . . . . . . . . . . . . . . . . 87
6.2 Conguring Security Event Notication . . . . . . . . . . . . . . . . 88
6.3 Conguring Reports . . . . . . . . . . . . . . . . . . . . . . . . 91
6.4 Reacting to Security Event Rejections . . . . . . . . . . . . . . . . 110
6.5 Maintaining Your Security Proles . . . . . . . . . . . . . . . . . 111
7 Support 113
7.1 Updating Novell AppArmor Online . . . . . . . . . . . . . . . . . 113
7.2 Using the Man Pages . . . . . . . . . . . . . . . . . . . . . . . 113
7.3 For More Information . . . . . . . . . . . . . . . . . . . . . . 115
7.4 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.5 Reporting Bugs for AppArmor . . . . . . . . . . . . . . . . . . . 117
A Background Information on AppArmor Proling 119
B GNU Licenses 121
B.1 GNU General Public License . . . . . . . . . . . . . . . . . . . . 121
B.2 GNU Free Documentation License . . . . . . . . . . . . . . . . . 129
Glossary 139
About This Guide
Novell® AppArmor is designed to provide easy-to-use application security for both
servers and workstations. Novell AppArmor is an access control system that lets you
specify per program which les the program may read, write, and execute. AppArmor
secures applications by enforcing good application behavior without relying on attack
signatures, so can prevent attacks even if they are exploiting previously unknown vulnerabilities.
Novell AppArmor consists of:
• A library of AppArmor proles for common Linux* applications describing what
les the program needs to access.
• A library of AppArmor prole foundation classes (prole building blocks) needed
for common application activities, such as DNS lookup and user authentication.
• A tool suite for developing and enhancing AppArmor proles, so that you can
change the existing proles to suit your needs and create new proles for your own
local and custom applications.
• Several specially modied applications that are AppArmor enabled to provide enhanced security in the form of unique subprocess connement, including Apache
and Tomcat.
• The Novell AppArmor–loadable kernel module and associated control scripts to
enforce AppArmor policies on your openSUSE™ system.
This guide covers the following topics:
Immunizing Programs
Describes the operation of Novell AppArmor and describes the types of programs
that should have Novell AppArmor proles created for them.
Prole Components and Syntax
Introduces the prole components and syntax.
Building and Managing Proles With YaST
Describes how to use the AppArmor YaST modules to build, maintain and update
proles.
Building Proles via the Command Line
Describes how to use the AppArmor command line tools to build, maintain and
update proles.
Proling Your Web Applications Using ChangeHat
Enables you to create subproles for the Apache Web server that allow you to
tightly conne small sections of Web application processing.
Managing Proled Applications
Describes how to perform Novell AppArmor prole maintenance, which involves
tracking common issues and concerns.
Support
Indicates support options for this product.
Glossary
Provides a list of terms and their denitions.
1 Feedback
We want to hear your comments and suggestions about this manual and the other documentation included with this product. Please use the User Comments feature at the
bottom of each page of the online documentation and enter your comments there.
2 Documentation Conventions
The following typographical conventions are used in this manual:
• /etc/passwd: lenames and directory names
• placeholder: replace placeholder with the actual value
• PATH: the environment variable PATH
• ls, --help: commands, options, and parameters
• user: users or groups
vi Novell AppArmor Administration Guide
•
Alt, Alt + F1: a key to press or a key combination; keys are shown in uppercase as
on a keyboard
•
File, File → Save As: menu items, buttons
•
Dancing Penguins (Chapter Penguins, ↑Reference): This is a reference to a chapter
in another book.
3 Source Code
The source code of openSUSE is publicly available. To download the source code,
proceed as outlined under http://www.novell.com/products/suselinux/
source_code.html. If requested we send you the source code on a DVD. We need
to charge a $15 or €15 fee for creation, handling and postage. To request a DVD of the
source code, send an e-mail to sourcedvd@suse.de [mailto:sourcedvd@suse
.de] or mail the request to:
SUSE Linux Products GmbH
Product Management openSUSE
Maxfeldstr. 5
D-90409 Nürnberg
Germany
About This Guide vii
Immunizing Programs
Novell® AppArmor provides immunization technologies that protect applications from
the inherent vulnerabilities they possess. After installing Novell AppArmor, setting up
Novell AppArmor proles, and rebooting the computer, your system becomes immunized because it begins to enforce the Novell AppArmor security policies. Protecting
programs with Novell AppArmor is referred to as immunizing.
Novell AppArmor sets up a collection of default application proles to protect standard
Linux services. In order to protect other applications, use the Novell AppArmor tools
to create proles for the applications that you want protected. This chapter introduces
the philosophy of immunizing programs. Proceed to Chapter 2, Prole Components
and Syntax (page 19), Chapter 3, Building and Managing Proles With YaST (page 23),
or Chapter 4, Building Proles via the Command Line (page 45) if you are ready to
build and manage Novell AppArmor proles.
Novell AppArmor provides streamlined access control for network services by specifying
which les each program is allowed to read, write, and execute. This ensures that each
program does what it is supposed to do and nothing else. Novell AppArmor quarantines
programs to protect the rest of the system from being damaged by a compromised
process.
Novell AppArmor is a host intrusion prevention, or mandatory access control scheme.
Previously, access control schemes were centered around users because they were built
for large timeshare systems. Alternatively, modern network servers largely do not permit
users to log in, but instead provide a variety of network services for users, such as Web,
mail, le, and print. Novell AppArmor controls the access given to network services
and other programs to prevent weaknesses from being exploited.
1
Immunizing Programs 9
TIP: Background Information for Novell AppArmor
To get a more in-depth overview of AppArmor and the overall concept behind
it, refer to Appendix A, Background Information on AppArmor Proling
(page 119).
1.1 Introducing the AppArmor Framework
The following section provides you with a very basic understanding of what is happening
“behind the scenes” (and under the hood of the YaST interface) when you run AppArmor.
An AppArmor prole is a plain text le containing path entries and access permissions,
see Section 2.1, “Breaking a Novell AppArmor Prole into Its Parts” (page 19) for a
detailed reference prole. The directives contained in this text le are then enforced
by the AppArmor routines to quarantine the process/program.
The following tools interact in the building and enforcement of AppArmor proles and
policies:
aa-unconned
aa-unconned detects any application running on your system that listens for network connections and is not protected by an AppArmor prole. Refer to Section
“aa-unconned—Identifying Unprotected Processes” (page 67) for detailed infor-
mation on this tool.
aa-autodep
aa-autodep creates a basic skeleton of a prole that needs to be eshed out before
it is put to productive use. The resulting prole is loaded and put into complain
mode, reporting any behavior of the application that is not (yet) covered by AppArmor rules. Refer to Section “aa-autodep—Creating Approximate Proles”
(page 52) for detailed information on this tool.
aa-genprof
aa-genprof generates a basic prole and asks you to rene this prole by executing
the application and thus generating log events that need to be taken care of by
10 Novell AppArmor Administration Guide
AppArmor policies. You will be guided through a series of questions to deal with
the log events that have been triggered during the application's execution. After
the prole has been generated, it gets loaded and put into enforce mode. Refer to
Section “aa-genprof—Generating Proles” (page 55) for detailed information on
this tool.
aa-logprof
aa-logprof interactively scans and reviews the log entries generated by an application
that is conned by an AppArmor prole in complain mode. It assists you in generating new entries in the prole concerned. Refer to Section “aa-logprof—Scanning
the System Log” (page 61) for detailed information on this tool.
aa-complain
aa-complain toggles the mode of an AppArmor prole from enforce to complain.
Exceptions to rules set in a prole are logged, but the prole is not enforced. Refer
to Section “aa-complain—Entering Complain or Learning Mode” (page 53) for
detailed information on this tool.
aa-enforce
aa-enforce toggles the mode of an AppArmor prole form complain to enforce.
Exceptions to rules set in a prole are logged, but not permitted—the prole is
enforced. Refer to Section “aa-enforce—Entering Enforce Mode” (page 54) for
detailed information on this tool.
Once a prole has been built and is loaded, there are two ways in which it can get processed:
complain
In complain mode, violations of AppArmor prole rules, such as the proled program accessing les not permitted by the prole, are detected. The violations are
permitted, but also logged. To improve the prole, turn complain mode on, run the
program through a suite of tests to generate log events that characterize the program's
access needs, then postprocess the log with the AppArmor tools (YaST or aa-logprof) to transform log events into improved proles.
enforce
In enforce mode, violations of AppArmor prole rules, such as the proled program
accessing les not permitted by the prole, are detected. The violations are logged
and not permitted. The default is for enforce mode to be enabled. To log the violations only, but still permit them, use complain mode. Enforce toggles with complain
mode.
Immunizing Programs 11
1.2 Determining Programs to Immunize
Now that you have familiarized yourself with AppArmor, start selecting the applications
to build proles for. Programs that need proling are those that mediate privilege. The
following programs have access to resources that the person using the program does
not have, so they grant the privilege to the user when used:
cron Jobs
Programs that are run periodically by cron. Such programs read input from a variety
of sources and can run with special privileges, sometimes with as much as root
privilege. For example, cron can run /usr/sbin/logrotate daily to rotate,
compress or even mail system logs. For instructions for nding these types of
programs, refer to Section 1.3, “Immunizing Cron Jobs” (page 13).
Web Applications
Programs that can be invoked through a Web browser, including CGI Perl scripts,
PHP pages, and more complex Web applications. For instructions for nding these
types of programs, refer to Section 1.4.1, “Immunizing Web Applications”
(page 15).
Network Agents
Programs (servers and clients) that have open network ports. User clients, such as
mail clients and Web browsers mediate privilege. These programs run with the
privilege to write to the user's home directory and they process input from potentially hostile remote sources, such as hostile Web sites and e-mailed malicious
code. For instructions for nding these types of programs, refer to Section 1.4.2,
“Immunizing Network Agents” (page 17).
Conversely, unprivileged programs do not need to be proled. For instance, a shell
script might invoke the cp program to copy a le. Because cp does not have its own
prole, it inherits the prole of the parent shell script, so can copy any les that the
parent shell script's prole can read and write.
12 Novell AppArmor Administration Guide
1.3 Immunizing Cron Jobs
To nd programs that are run by cron, inspect your local cron conguration. Unfortunately, cron conguration is rather complex, so there are numerous les to inspect.
Periodic cron jobs are run from these les:
/etc/crontab
/etc/cron.d/*
/etc/cron.daily/*
/etc/cron.hourly/*
/etc/cron.monthly/*
/etc/cron.weekly/*
For root's cron jobs, edit the tasks with crontab -e and list root's cron tasks
with crontab -l. You must be root for these to work.
Once you nd these programs, you can use the Add Prole Wizard to create proles
for them. Refer to Section 3.1, “Adding a Prole Using the Wizard” (page 25).
1.4 Immunizing Network Applications
An automated method for nding network server daemons that should be proled is to
use the aa-unconned tool. You can also simply view a report of this information in
the YaST module (refer to Section “Application Audit Report” (page 97) for instructions).
The aa-unconned tool uses the command netstat -nlp to inspect your open ports
from inside your computer, detect the programs associated with those ports, and inspect
the set of Novell AppArmor proles that you have loaded. aa-unconned then reports
these programs along with the Novell AppArmor prole associated with each program
or reports “none” if the program is not conned.
NOTE
If you create a new prole, you must restart the program that has been proled
to have it be effectively conned by AppArmor.
Immunizing Programs 13
Below is a sample aa-unconned output:
2325 /sbin/portmap not confined
3702❶ /usr/sbin/sshd❷ confined
by '/usr/sbin/sshd❸ (enforce)'
4040 /usr/sbin/ntpd confined by '/usr/sbin/ntpd (enforce)'
4373 /usr/lib/postfix/master confined by '/usr/lib/postfix/master (enforce)'
4505 /usr/sbin/httpd2-prefork confined by '/usr/sbin/httpd2-prefork (enforce)'
5274 /sbin/dhcpcd not confined
5592 /usr/bin/ssh not confined
7146 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (complain)'
The rst portion is a number. This number is the process ID number (PID) of the
❶
listening program.
The second portion is a string that represents the absolute path of the listening
❷
program
The nal portion indicates the prole conning the program, if any.
❸
NOTE
aa-unconned requires root privileges and should not be run from a shell
that is conned by an AppArmor prole.
aa-unconned does not distinguish between one network interface and another, so it
reports all unconned processes, even those that might be listening to an internal LAN
interface.
Finding user network client applications is dependent on your user preferences. The
aa-unconned tool detects and reports network ports opened by client applications, but
only those client applications that are running at the time the aa-unconned analysis is
performed. This is a problem because network services tend to be running all the time,
while network client applications tend only to be running when the user is interested
in them.
Applying Novell AppArmor proles to user network client applications is also dependent
on user preferences. Therefore, we leave proling of user network client applications
as an exercise for the user.
To aggressively conne desktop applications, the aa-unconned command supports a
paranoid option, which reports all processes running and the corresponding App-
14 Novell AppArmor Administration Guide
Armor proles that might or might not be associated with each process. The user can
then decide whether each of these programs needs an AppArmor prole.
If you have new or modied proles, you can submit them to the apparmor-general@forge.novell.com [mailto:apparmor-general@forge.novell.com]
mailing list along with a use case for the application behavior that you exercised. The
AppArmor team reviews and may submit the work into openSUSE. We cannot guarantee
that every prole will be included, but we make a sincere effort to include as much as
possible so that end users can contribute to the security proles that ship in openSUSE.
1.4.1 Immunizing Web Applications
To nd Web applications, investigate your Web server conguration. The Apache Web
server is highly congurable and Web applications can be stored in many directories,
depending on your local conguration. openSUSE, by default, stores Web applications
in /srv/www/cgi-bin/. To the maximum extent possible, each Web application
should have an Novell AppArmor prole.
Once you nd these programs, you can use the AppArmor Add Prole Wizard to create
proles for them. Refer to Section 3.1, “Adding a Prole Using the Wizard” (page 25).
Because CGI programs are executed by the Apache Web server, the prole for Apache
itself, usr.sbin.httpd2-prefork for Apache2 on openSUSE, must be modied
to add execute permissions to each of these programs. For instance, adding the line
/srv/www/cgi-bin/my_hit_counter.pl rpx grants Apache permission to
execute the Perl script my_hit_counter.pl and requires that there be a dedicated
prole for my_hit_counter.pl. If my_hit_counter.pl does not have a dedicated prole associated with it, the rule should say
/srv/www/cgi-bin/my_hit_counter.pl rix to cause my_hit_counter
.pl to inherit the usr.sbin.httpd2-prefork prole.
Some users might nd it inconvenient to specify execute permission for every CGI
script that Apache might invoke. Instead, the administrator can grant controlled access
to collections of CGI scripts. For instance, adding the line
/srv/www/cgi-bin/*.{pl,py,pyc} rix allows Apache to execute all les
in /srv/www/cgi-bin/ ending in .pl (Perl scripts) and .py or .pyc (Python
scripts). As above, the ix part of the rule causes Python scripts to inherit the Apache
prole, which is appropriate if you do not want to write individual proles for each
Python script.
Immunizing Programs 15
NOTE
If you want the subprocess connement module (apache2-mod-apparmor)
functionality when Web applications handle Apache modules (mod_perl and
mod_php), use the ChangeHat features when you add a prole in YaST or at
the command line. To take advantage of the subprocess connement, refer to
Section 5.1, “Apache ChangeHat” (page 76).
Proling Web applications that use mod_perl and mod_php requires slightly different
handling. In this case, the “program” is a script interpreted directly by the module
within the Apache process, so no exec happens. Instead, the Novell AppArmor version
of Apache calls change_hat() using a subprole (a “hat”) corresponding to the
name of the URI requested.
NOTE
The name presented for the script to execute might not be the URI, depending
on how Apache has been congured for where to look for module scripts. If
you have congured your Apache to place scripts in a different place, the different names appear in log le when Novell AppArmor complains about access
violations. See Chapter 6, Managing Proled Applications (page 87).
For mod_perl and mod_php scripts, this is the name of the Perl script or the PHP
page requested. For example, adding this subprole allows the localtime.php page
to execute and access the local system time:
/usr/bin/httpd2-prefork {
# ...
^/cgi-bin/localtime.php {
/etc/localtime r,
/srv/www/cgi-bin/localtime.php r,
/usr/lib/locale/** r,
}
}
If no subprole has been dened, the Novell AppArmor version of Apache applies the
DEFAULT_URI hat. This subprole is basically sufcient to display an HTML Web
page. The DEFAULT_URI hat that Novell AppArmor provides by default is the following:
16 Novell AppArmor Administration Guide
/usr/sbin/suexec2 ixr,
/var/log/apache2/** rwl,
/home/*/public_html/** r,
/srv/www/htdocs/** r,
/srv/www/icons/*.{gif,jpg,png} r,
/usr/share/apache2/** r,
To use a single Novell AppArmor prole for all Web pages and CGI scripts served by
Apache, a good approach is to edit the DEFAULT_URI subprole.
1.4.2 Immunizing Network Agents
To nd network server daemons and network clients (such as fetchmail, Firefox, amaroK
or Banshee) that should be proled, you should inspect the open ports on your machine,
consider the programs that are answering on those ports, and provide proles for as
many of those programs as possible. If you provide proles for all programs with open
network ports, an attacker cannot get to the le system on your machine without passing
through a Novell AppArmor prole policy.
Scan your server for open network ports manually from outside the machine using a
scanner, such as nmap, or from inside the machine using the netstat --inet -n
-p command. Then inspect the machine to determine which programs are answering
on the discovered open ports.
TIP
Refer to the man page of the netstat command for a detailed reference of
all possible options.
Immunizing Programs 17
Prole Components and
Syntax
This chapter explains the components and syntax of Novell® AppArmor proles. You
are ready to build Novell AppArmor proles after you select the programs to prole.
For help with this, refer to Section 1.2, “Determining Programs to Immunize” (page 12).
To start building AppArmor proles with YaST, proceed to Chapter 3, Building and
Managing Proles With YaST (page 23). To build proles using the AppArmor com-
mand line interface, proceed to Chapter 4, Building Proles via the Command Line
(page 45).
2.1 Breaking a Novell AppArmor
Prole into Its Parts
Novell AppArmor prole components are called Novell AppArmor rules. Currently
there are two main types of Novell AppArmor rules, path entries and capability entries.
Path entries specify what the process can access in the le system and capability entries
provide a more ne-grained control over what a conned process is allowed to do
through other system calls that require privileges. Includes are a type of meta rule or
directives that pull in path and capability entries from other les.
The easiest way of explaining what a prole consists of and how to create one is to
show the details of a sample prole. Consider, for example, the following shortened
prole for the program /usr/lib/postfix/flush (for the complete version, refer
to /etc/apparmor.d/usr.lib.postfix.flush):
2
Prole Components and Syntax 19
# profile to confine postfix/flush❶
#include <tunables/global>❷
/usr/lib/postfix/flush❸
{❹
#include <abstractions/base>❺
...
capability setgid❻,
...
/usr/lib/postfix/flush rix,
/{var/spool/postfix/,}❼deferred r,
...
/{var/spool/postfix/,}flush rwl,
...
/{var/spool/postfix/,}incoming r,
...
/{var/spool/postfix/,}public/qmgr w,
/etc/mtab❽ r,
/etc/postfix/main.cf r,
/etc/postfix/virtual.db r,
@{HOME}❾/.forward r,
/proc/stat r,
/proc/sys/kernel/ngroups_max r,
/var/spool/postfix/pid/unix.flush rw,
}
A comment naming the program that is conned by this prole. Always precede
❶
comments like this with the # sign.
This loads a le containing variable denitions.
❷
The absolute path to the program that is conned.
❸
The curly braces ({}) serve as a container for include statements of other proles
❹
as well as for path and capability entries.
This directive pulls in components of Novell AppArmor proles to simplify pro-
❺
les.
Capability entry statements enable each of the 29 POSIX.1e draft capabilities.
❻
The curly braces ({}) make this rule apply to the path both with and without the
❼
content enclosed by the braces.
A path entry specifying what areas of the le system the program can access. The
❽
rst part of a path entry species the absolute path of a le (including regular
expression globbing) and the second part indicates permissible access modes (r
for read, w for write, and x for execute). A whitespace of any kind (spaces or tabs)
can precede pathnames or separate the pathname from the access modes. Spaces
20 Novell AppArmor Administration Guide
between the access mode and the trailing comma is optional. A comprehensive
overview of the access modes available can be found in Section 4.8, “File Permis-
sion Access Modes” (page 69).
This variable expands to a value that can be changed without changing the entire
❾
prole.
TIP: Using Variables in Proles
With the current AppArmor tools, variables as presented in the above example
can only be used when manually editing and maintaining a prole.
A typical example when variables come in handy are network scenarios in which
user home directories are not mounted in the standard location /home/
username, but under a custom location. Find the variable denitions for this
use case (@{HOME} and @{HOMEDIRS}) in the /etc/apparmor.d/
tunables/home le.
When a prole is created for a program, the program can access only the les, modes,
and POSIX capabilities specied in the prole. These restrictions are in addition to the
native Linux access controls.
Example: To gain the capability CAP_CHOWN, the program must have both access
to CAP_CHOWN under conventional Linux access controls (typically, be a root-owned
process) and have the capability chown in its prole. Similarly, to be able to write to
the le /foo/bar the program must have both the correct user ID and mode bits set
in the les attributes (see the chmod and chown man pages) and have /foo/bar
w in its prole.
Attempts to violate Novell AppArmor rules are recorded in /var/log/audit/
audit.log if the audit package is installed or otherwise in /var/log/messages.
In many cases, Novell AppArmor rules prevent an attack from working because necessary les are not accessible and, in all cases, Novell AppArmor connement restricts
the damage that the attacker can do to the set of les permitted by Novell AppArmor.
2.2 #include Statements
#include statements are directives that pull in components of other Novell AppArmor
proles to simplify proles. Include les fetch access permissions for programs. By
Prole Components and Syntax 21
using an include, you can give the program access to directory paths or les that are
also required by other programs. Using includes can reduce the size of a prole.
By default, AppArmor adds /etc/apparmor.d to the path in the #include
statement. AppArmor expects the include les to be located in /etc/apparmor.d.
Unlike other prole statements (but similar to C programs), #include lines do not
end with a comma.
To assist you in proling your applications, Novell AppArmor provides two classes of
#includes: abstractions and program chunks.
2.2.1 Abstractions
Abstractions are #includes that are grouped by common application tasks. These
tasks include access to authentication mechanisms, access to name service routines,
common graphics requirements, and system accounting. Files listed in these abstractions
are specic to the named task. Programs that require one of these les usually require
some of the other les listed in the abstraction le (depending on the local conguration
as well as the specic requirements of the program). Find abstractions in /etc/
apparmor.d/abstractions.
2.2.2 Program Chunks
The program-chunks directory (/etc/apparmor.d/program-chunks) contains
some chunks of proles that are specic to program suites and not generally useful
outside of the suite, thus are never suggested for use in proles by the prole wizards
(aa-logprof and aa-genprof). Currently program chunks are only available for the
postx program suite.
2.3 Capability Entries (POSIX.1e)
Capabilities statements are simply the word capability followed by the name of
the POSIX.1e capability as dened in the capabilities(7) man page.
22 Novell AppArmor Administration Guide
Building and Managing
Proles With YaST
There are two three ways you can build and manage Novell® AppArmor, depending
on whether you want to work in a graphical user environment or whether you prefer
the less resource consuming text or command line based approach:
Graphical YaST Interface
The graphical YaST interface to AppArmor was designed to provide the most
convenient access to AppArmor. It is most suitable for use with a high bandwidth
connection or working on a local machine. A detailed description is given below.
Text-based YaST Interface (ncurses)
The ncurses interfaces to YaST AppArmor offers the same functionality as the
graphical interface while consuming less resources and bandwidth. It is not described
separately, since it works similar as the graphical interface. A general introduction
into use and navigation of the YaST ncurses interface can be found in Chapter 4,
YaST in Text Mode (↑Reference).
AppArmor Command Line
AppArmor offers a purely command line-based interface which can be used to
control AppArmor from a terminal window or via remote connections. It is described
in more detail in Chapter 4, Building Proles via the Command Line (page 45).
Start YaST from the main menu and enter your root password when prompted for it.
Alternatively, start YaST by opening a terminal window, logging in as root, and entering yast2.
3
Building and Managing Proles With YaST 23
If Novell AppArmor is not available, try installing or reinstalling the Novell AppArmor
software. The right frame shows the Novell AppArmor options:
Add Prole Wizard
For detailed steps, refer to Section 3.1, “Adding a Prole Using the Wizard”
(page 25).
Manually Add Prole
Add a Novell AppArmor prole for an application on your system without the help
of the wizard. For detailed steps, refer to Section 3.2, “Manually Adding a Prole”
(page 32).
Edit Prole
Edits an existing Novell AppArmor prole on your system. For detailed steps, refer
to Section 3.3, “Editing Proles” (page 33).
Delete Prole
Deletes an existing Novell AppArmor prole from your system. For detailed steps,
refer to Section 3.4, “Deleting a Prole” (page 38).
Update Prole Wizard
For detailed steps, refer to Section 3.5, “Updating Proles from Log Entries”
(page 39).
24 Novell AppArmor Administration Guide
AppArmor Reports
For detailed steps, refer to Section 6.3, “Conguring Reports” (page 91).
AppArmor Control Panel
For detailed steps, refer to Section 3.6, “Managing Novell AppArmor and Security
Event Status” (page 40).
3.1 Adding a Prole Using the Wizard
The Add Prole Wizard is designed to set up Novell AppArmor proles using the
Novell AppArmor proling tools, aa-genprof (Generate Prole) and aa-logprof (Update
Proles from Learning Mode Log File). For more information about these tools, refer
to Section 4.6.3, “Summary of Proling Tools” (page 52).
Stop the application before proling it to ensure that the application start-up is
1
included in the prole. To do this, make sure that the application or daemon is
not running.
For example, enter /etc/init.d/PROGRAM stop in a terminal window
while logged in as root, replacing PROGRAM with the name of the program to
prole.
Start YaST and select Novell AppArmor → Add Prole Wizard.
2
Building and Managing Proles With YaST 25
Enter the name of the application or browse to the location of the program.
3
Click Create. This runs a Novell AppArmor tool named aa-autodep, which per-
4
forms a static analysis of the program to prole and loads an approximate prole
into Novell AppArmor module. For more information about aa-autodep, refer to
Section “aa-autodep—Creating Approximate Proles” (page 52).
The AppArmor Prole Wizard window opens.
In the background, Novell AppArmor also sets the prole to learning mode. For
more information about learning mode, refer to Section “aa-complain—Entering
Complain or Learning Mode” (page 53).
Run the application to prole.
5
Perform as many of the application functions as possible so learning mode can
6
log the les and directories to which the program requires access to function
properly. Be sure to include restarting and stopping the program in the exercised
functions. AppArmor needs to handle these events as well as any other program
function.
Click Scan system log for AppArmor events to parse the learning mode log les.
7
This generates a series of questions that you must answer to guide the wizard in
generating the security prole.
26 Novell AppArmor Administration Guide
If requests to add hats appear, proceed to Chapter 5, Proling Your Web Appli-
cations Using ChangeHat (page 75).
The questions fall into two categories:
• A resource is requested by a proled program that is not in the prole (see
Figure 3.1, “Learning Mode Exception: Controlling Access to Specic Resources” (page 28)). Allow or deny access to a specic resource.
• A program is executed by the proled program and the security domain
transition has not been dened (see Figure 3.2, “Learning Mode Exception:
Dening Execute Permissions for an Entry” (page 28)). Dene execute
permissions for an entry.
Each of these cases results in a series of questions that you must answer to add
the resource to the prole or to add the program into the prole. The following
two gures show an example of each case. Subsequent steps describe your options
in answering these questions.
NOTE: Varying Processing Options
Not all of the options introduced below are always present. The options
displayed depend on the type of entry processed.
Building and Managing Proles With YaST 27
Figure 3.1
Learning Mode Exception: Controlling Access to Specic Resources
Figure 3.2
The Add Prole Wizard begins suggesting directory path entries that have been
8
accessed by the application you are proling (as seen in Figure 3.1, “Learning
Mode Exception: Controlling Access to Specic Resources” (page 28)) or re-
Learning Mode Exception: Dening Execute Permissions for an Entry
28 Novell AppArmor Administration Guide
quires you to dene execute permissions for entries (as seen in Figure 3.2,
“Learning Mode Exception: Dening Execute Permissions for an Entry”
(page 28)).
• For Figure 3.1: Learning Mode Exception: Controlling Access to Specic
Resources: From the following options, select the one that satises the request
for access, which could be a suggested include, a particular globbed version
of the path, or the actual pathname. Note that all of these options are not always available.
#include
The section of a Novell AppArmor prole that refers to an include le.
Include les give access permissions for programs. By using an include,
you can give the program access to directory paths or les that are also
required by other programs. Using includes can reduce the size of a
prole. It is good practice to select includes when suggested.
Globbed Version
Accessed by clicking Glob. For information about globbing syntax, refer
to Section 4.7, “Pathnames and Globbing” (page 68).
Actual Pathname
Literal path that the program needs to access to run properly.
After you select a directory path, process it as an entry into the Novell AppArmor prole by clicking Allow or Deny. If you are not satised with the
directory path entry as it is displayed, you can also Glob or Edit it.
The following options are available to process the learning mode entries and
build the prole:
Allow
Grant the program access to the specied directory path entries. The
Add Prole Wizard suggests le permission access. For more information
about this, refer to Section 4.8, “File Permission Access Modes”
(page 69).
Deny
Click Deny to prevent the program from accessing the specied paths.
Building and Managing Proles With YaST 29
Glob
Clicking this modies the directory path (by using wild cards) to include
all les in the suggested directory. Double-clicking it grants access to
all les and subdirectories beneath the one shown.
For more information about globbing syntax, refer to Section 4.7,
“Pathnames and Globbing” (page 68).
Glob w/Ext
Modify the original directory path while retaining the lename extension.
A single click causes /etc/apache2/file.ext to become /etc/
apache2/*.ext, adding the wild card (asterisk) in place of the lename. This allows the program to access all les in the suggested directories that end with the .ext extension. When you double-click it, access
is granted to all les (with the particular extension) and subdirectories
beneath the one shown.
Edit
Edit the highlighted line. The new (edited) line appears at the bottom of
the list.
Abort
Abort aa-logprof, losing all rule changes entered so far and leaving all
proles unmodied.
Finish
Close aa-logprof, saving all rule changes entered so far and modifying
all proles.
Click Allow or Deny for each learning mode entry. These help build the
Novell AppArmor prole.
NOTE
The number of learning mode entries corresponds to the complexity
of the application.
• For Figure 3.2: Learning Mode Exception: Dening Execute Permissions
for an Entry: From the following options, select the one that satises the re-
30 Novell AppArmor Administration Guide
Loading...