Novell APPARMOR 2.0 Instruction Manual

Novell AppArmor
www.novell.com2.0
August28,2006 Novell AppArmor 2.0 Administration Guide

Novell AppArmor 2.0 Administration Guide
List of Authors: Leona Beatrice Campbell, Jana Jaeger
This publication is intellectual property of Novell Inc.
Its contents can be duplicated, either in part or in whole, provided that a copyright label is visibly lo-
cated on each copy.
All information found in this book has been compiled with utmost attention to detail. However, this
does not guarantee complete accuracy. Neither SUSE LINUX GmbH, the authors, nor the translators
shall be held liable for possible errors or the consequences thereof.
Novell, the Novell logo, the N logo and SUSE 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.

Contents
About This Guide v
1Immunizing Programs 9
2Selecting Programs to Immunize 11
2.1 Immunize Programs That Grant Privilege . . . . . . . . . . . . . . . 11
2.2 Inspect Open Ports to Immunize Programs . . . . . . . . . . . . . . 12
3Building Novell AppArmor Proles 19
3.1 Prole Components and Syntax . . . . . . . . . . . . . . . . . . . 19
3.2 Building and Managing Novell AppArmor Proles . . . . . . . . . . . 23
3.3 Building Novell AppArmor Proles with the YaST GUI . . . . . . . . . . 24
3.4 Building Novell AppArmor Proles Using the Command Line Interface . . 47
3.5 Two Methods of Proling . . . . . . . . . . . . . . . . . . . . . . 51
3.6 Pathnames and Globbing . . . . . . . . . . . . . . . . . . . . . . 69
3.7 File Permission Access Modes . . . . . . . . . . . . . . . . . . . . 71
4Managing Proled Applications 77
4.1 Monitoring Your Secured Applications . . . . . . . . . . . . . . . . 77
4.2 Setting Up Event Notication . . . . . . . . . . . . . . . . . . . . 78
4.3 Reports............................. 81
4.4 Reacting to Security Events . . . . . . . . . . . . . . . . . . . . 102
4.5 Maintaining Your Security Proles . . . . . . . . . . . . . . . . . 102
5Proling Your Web Applications Using ChangeHat Apache 105
5.1 ApacheChangeHat........................ 106

5.2 Apache Conguration for apache2-mod-apparmor . . . . . . . . . . 113
6Support 117
6.1 Updating Novell AppArmor Online . . . . . . . . . . . . . . . . . 117
6.2 Using the Man Pages . . . . . . . . . . . . . . . . . . . . . . . 117
6.3 For More Information . . . . . . . . . . . . . . . . . . . . . . 119
6.4 Troubleshooting......................... 120
6.5 Reporting Bugs for AppArmor . . . . . . . . . . . . . . . . . . . 121
ABackground Information on AppArmor Proling 123
Glossary 125

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 vul-
nerabilities.
Novell AppArmor consists of:
• A library of AppArmor proles for common Linux* applications describing what
les the program needs to access.
• A library of AppArmor prole foundation classes (prole building blocks) needed
for common application activities, such as DNS lookup and user authentication.
• A tool suite for developing and enhancing AppArmor proles, so that you can
change the existing proles to suit your needs and create new proles for your own
local and custom applications.
• Several specially modied applications that are AppArmor enabled to provide en-
hanced security in the form of unique subprocess connement, including Apache.
• The Novell AppArmor–loadable kernel module and associated control scripts to
enforce AppArmor policies on your SUSE® Linux system.
This guide covers the following topics:
Immunizing Programs
Describes the operation of Novell AppArmor.
Selecting Programs to Immunize
Describes the types of programs that should have Novell AppArmor proles created
for them.
Building Novell AppArmor Proles
Describes how to use the Novell AppArmor tools to immunize your own programs
and third-party programs that you may have installed on your SUSE Linux system.

It also helps you to add, edit, or delete proles that have been created for your ap-
plications.
Managing Proled Applications
Describes how to perform Novell AppArmor prole maintenance, which involves
tracking common issues and concerns.
Proling Your Web Applications Using ChangeHat Apache
Enables you to create subproles for the Apache Web server that allow you to
tightly conne small sections of Web application processing.
Support
Indicates support options for this product.
Glossary
Provides a list of terms and their denitions.
NOTE
Novell AppArmor ships with any SUSE Linux–based Novell operating system.
Text references to SUSE Linux apply to SUSE Linux OSS, the SUSE Linux retail
product, and the SUSE Linux Enterprise product family.
1 Feedback
We want to hear your comments and suggestions about this manual and the other doc-
umentation 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
vi Novell AppArmor 2.0 Administration Guide

•PATH: the environment variable PATH
•ls,--help: commands, options, and parameters
•user: users or groups
•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.
About This Guide vii

1
Immunizing Programs
Novell® AppArmor provides immunization technologies that protect SUSE Linux ap-
plications from the inherent vulnerabilities they possess. After installing Novell App-
Armor, setting up Novell AppArmor proles, 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 proles to protect standard
Linux services. To protect other applications, use the Novell AppArmor tools to create
proles for the applications that you want protected. This chapter introduces the philos-
ophy of immunizing programs. Proceed to Chapter 3, Building Novell AppArmor Proles
(page 19) if you are ready to build and manage Novell AppArmor proles.
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 is host intrusion prevention, or mandatory access control scheme,
that is optimized for servers. 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.
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 Proling
(page 123).
10 Novell AppArmor 2.0 Administration Guide

2
Selecting Programs to
Immunize
Novell® AppArmor quarantines programs to protect the rest of the system from being
damaged by a compromised process. You should inspect your ports to see which pro-
grams should be proled (refer to Section 2.2, “Inspect Open Ports to Immunize Pro-
grams” (page 12)) and prole all programs that grant privilege (Section 2.1, “Immunize
Programs That Grant Privilege” (page 11)).
2.1 Immunize Programs That Grant
Privilege
Programs that need proling 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/bin/updatedb daily to keep the
locate database up to date with sufcient privilege to read the name of every le
in the system. For instructions for nding these types of programs, refer to Sec-
tion 2.2.1, “Immunizing Cron Jobs” (page 14).
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
Selecting Programs to Immunize 11

types of programs, refer to Section 2.2.2, “Immunizing Web Applications”
(page 14).
Network Agents
Programs (servers and clients) that have open network ports. User clients, such as
mail clients and Web browsers, surprisingly, 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 Sec-
tion 2.2.3, “Immunizing Network Agents” (page 16).
Conversely, unprivileged programs do not need to be proled. For instance, a shell
script might invoke the cp program to copy a le. Because cp does not have its own
prole, it inherits the prole of the parent shell script, so can copy any les that the
parent shell script's prole can read and write.
2.2 Inspect Open Ports to Immunize
Programs
An automated method for nding network server daemons that should be proled is to
use the aa-unconned tool. You can also simply view a report of this information in
the YaST GUI (refer to Section “Application Audit Report” (page 87) for instructions).
The aa-unconned 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 proles that you have loaded. aa-unconned then reports
these programs along with the Novell AppArmor prole associated with each program
or reports “none” if the program is not conned.
NOTE
If you create a new prole, you must restart the program that has been proled
to have it be effectively conned by AppArmor.
Below is a sample aa-unconned output:
2325 /sbin/portmap not confined
3702❶/usr/sbin/sshd❷confined
by '/usr/sbin/sshd❸(enforce)'
12 Novell AppArmor 2.0 Administration Guide

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 prole conning the program, if any.
NOTE
aa-unconned requires root privileges and should not be run from a shell
that is conned by an AppArmor prole.
aa-unconned does not distinguish between one network interface and another, so it
reports all unconned 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-unconned tool detects and reports network ports opened by client applications, but
only those client applications that are running at the time the aa-unconned 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 proles to user network client applications is also dependent
on user preferences and Novell AppArmor is intended for servers rather than worksta-
tions. Therefore, we leave proling of user network client applications as an exercise
for the user.
To aggressively conne desktop applications, the aa-unconned command supports a
paranoid option, which reports all processes running and the corresponding AppArmor
proles that might or might not be associated with each process. The user can then decide
whether each of these programs needs an AppArmor prole.
Selecting Programs to Immunize 13

If you have new or modied proles, you can submit them to the apparmor-gener-
[e-mail] [mailto:[email protected]]
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 prole will be included, but we make a sincere effort to include as much as
possible so that end users can contribute to the security proles that ship in openSUSE.
2.2.1 Immunizing Cron Jobs
To nd programs that are run by cron, inspect your local cron conguration. Unfortu-
nately, cron conguration 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 Prole Wizard to create proles
for them. Refer to Section 3.3.1, “Adding a Prole Using the Wizard” (page 26).
2.2.2 Immunizing Web Applications
To nd Web applications, investigate your Web server conguration. The Apache Web
server is highly congurable and Web applications can be stored in many directories,
depending on your local conguration. SUSE Linux, by default, stores Web applications
in /srv/www/cgi-bin/. To the maximum extent possible, each Web application
should have an Novell AppArmor prole.
Once you nd these programs, you can use the AppArmor Add Prole Wizard to create
proles for them. Refer to Section 3.3.1, “Adding a Prole Using the Wizard” (page 26).
14 Novell AppArmor 2.0 Administration Guide

CGI Programs and Subprocess Connement in Web
Applications
Because CGI programs are executed by the Apache Web server, the prole for Apache
itself, usr.sbin.httpd2-prefork for Apache2 on SUSE Linux, must be modied
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
prole for my_hit_counter.pl. If my_hit_counter.pl does not have a ded-
icated prole 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 prole.
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
prole, which is appropriate if you do not want to write individual proles for each
Python script.
NOTE
If you want the subprocess connement module (apache2-mod-apparmor)
functionality when Web applications handle Apache modules (mod_perl and
mod_php), use the ChangeHat features when you add a prole in YaST or at
the command line. To take advantage of the subprocess connement, refer to
Section 5.1, “Apache ChangeHat” (page 106).
Proling 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 subprole (a “hat”) corresponding to the
name of the URI requested.
Selecting Programs to Immunize 15

NOTE
The name presented for the script to execute might not be the URI, depending
on how Apache has been congured for where to look for module scripts. If
you have congured your Apache to place scripts in a different place, the dif-
ferent names appear in log le when Novell AppArmor complains about access
violations. See Chapter 4, Managing Proled Applications (page 77).
For mod_perl and mod_php scripts, this is the name of the Perl script or the PHP
page requested. For example, adding this subprole 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 subprole has been dened, the Novell AppArmor version of Apache applies the
DEFAULT_URI hat. This subprole is basically sufcient to display an HTML Web
page. The DEFAULT_URI hat that Novell AppArmor provides by default is the follow-
ing:
/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 prole for all Web pages and CGI scripts served by
Apache, a good approach is to edit the DEFAULT_URI subprole.
2.2.3 Immunizing Network Agents
To nd network server daemons and network clients (such as fetchmail, Firefox, or
XMMS) that should be proled, you should inspect the open ports on your machine,
consider the programs that are answering on those ports, and provide proles for as
many of those programs as possible. If you provide proles for all programs with open
16 Novell AppArmor 2.0 Administration Guide

network ports, an attacker cannot get to the le system on your machine without passing
through a Novell AppArmor prole 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.
Selecting Programs to Immunize 17

3
Building Novell AppArmor
Proles
This chapter explains how to build and manage Novell® AppArmor proles. You are
ready to build Novell AppArmor proles after you select the programs to prole. For
help with this, refer to Chapter 2, Selecting Programs to Immunize (page 11).
3.1 Prole Components and Syntax
This section details the syntax and makeup of Novell AppArmor proles. An example
illustrating this syntax is presented in Section 3.1.1, “Breaking a Novell AppArmor
Prole into Its Parts” (page 19).
3.1.1 Breaking a Novell AppArmor Prole
into Its Parts
Novell AppArmor prole 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 conned 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 prole consists of and how to create one is to
show the details of a sample prole. Consider, for example, the following shortened
Building Novell AppArmor Proles 19

prole for the program /usr/lib/postfix/flush (for the complete version, refer
to /etc/apparmor.d/usr.lib.postfix.flush):
# 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 conned by this prole. Always precede
comments like this with the #sign.
❷This loads a le containing variable denitions.
❸The absolute path to the program that is conned.
❹The curly braces ({}) serve as a container for include statements of other proles
as well as for path and capability entries.
❺This directive pulls in components of Novell AppArmor proles 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 species the absolute path of a le (including regular
expression globbing) and the second part indicates permissible access modes (r
20 Novell AppArmor 2.0 Administration Guide