1
# ----------------------------------------------------------------------
2
# Copyright (c) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
4
# NOVELL (All rights reserved)
7
# Canonical Ltd. (All rights reserved)
9
# This program is free software; you can redistribute it and/or
10
# modify it under the terms of version 2 of the GNU General Public
11
# License published by the Free Software Foundation.
13
# This program is distributed in the hope that it will be useful,
14
# but WITHOUT ANY WARRANTY; without even the implied warranty of
15
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
16
# GNU General Public License for more details.
18
# You should have received a copy of the GNU General Public License
19
# along with this program; if not, contact Novell, Inc.
20
# ----------------------------------------------------------------------
27
AppArmor - kernel enhancement to confine programs to a limited set of resources.
31
AppArmor is a kernel enhancement to confine programs to a limited set
32
of resources. AppArmor's unique security model is to bind access control
33
attributes to programs rather than to users.
35
AppArmor confinement is provided via I<profiles> loaded into the kernel
36
via apparmor_parser(8), typically through the F</etc/init.d/apparmor>
37
SysV initscript, which is used like this:
39
# /etc/init.d/apparmor start
40
# /etc/init.d/apparmor stop
41
# /etc/init.d/apparmor restart
43
AppArmor can operate in two modes: I<enforcement>, and I<complain or learning>:
49
I<enforcement> - Profiles loaded in enforcement mode will result
50
in enforcement of the policy defined in the profile as well as reporting
51
policy violation attempts to syslogd.
55
I<complain> - Profiles loaded in C<complain> mode will not enforce policy.
56
Instead, it will report policy violation attempts. This mode is convenient for
57
developing profiles. To manage complain mode for individual profiles the
58
utilities aa-complain(8) and aa-enforce(8) can be used.
59
These utilities take a program name as an argument.
64
Profiles are traditionally stored in files in F</etc/apparmor.d/>
65
under filenames with the convention of replacing the B</> in pathnames
66
with B<.> (except for the root B</>) so profiles are easier to manage
67
(e.g. the F</usr/sbin/nscd> profile would be named F<usr.sbin.nscd>).
69
Profiles are applied to a process at exec(3) time (as seen through the
70
execve(2) system call); an already running process cannot be confined.
71
However, once a profile is loaded for a program, that program will be
72
confined on the next exec(3).
74
AppArmor supports the Linux kernel's securityfs filesystem, and makes
75
available the list of the profiles currently loaded; to mount the
78
# mount -tsecurityfs securityfs /sys/kernel/security
79
$ cat /sys/kernel/security/apparmor/profiles
84
Normally, the initscript will mount securityfs if it has not already
87
AppArmor also restricts what privileged operations a confined process
88
may execute, even if the process is running as root. A confined process
89
cannot call the following system calls:
91
create_module(2) delete_module(2) init_module(2) ioperm(2)
92
iopl(2) mount(2) umount(2) ptrace(2) reboot(2) setdomainname(2)
93
sethostname(2) swapoff(2) swapon(2) sysctl(2)
95
A confined process can not call mknod(2) to create character or block devices.
99
When a confined process tries to access a file it does not have permission
100
to access, the kernel will report a message through audit, similar to:
102
audit(1148420912.879:96): REJECTING x access to /bin/uname
103
(sh(6646) profile /tmp/sh active /tmp/sh)
105
audit(1148420912.879:97): REJECTING r access to /bin/uname
106
(sh(6646) profile /tmp/sh active /tmp/sh)
108
audit(1148420944.837:98): REJECTING access to capability
109
'dac_override' (sh(6641) profile /tmp/sh active /tmp/sh)
112
The permissions requested by the process are immediately after
113
REJECTING. The "name" and process id of the running program are reported,
114
as well as the profile name and any "hat" that may be active. ("Name"
115
is in quotes, because the process name is limited to 15 bytes; it is the
116
same as reported through the Berkeley process accounting.) If no hat is
117
active (see aa_change_hat(2)) then the profile name is printed for "active".
119
For confined processes running under a profile that has been loaded in
120
complain mode, enforcement will not take place and the log messages
121
reported to audit will be of the form:
123
audit(1146868287.904:237): PERMITTING r access to
124
/etc/apparmor.d/tunables (du(3811) profile /usr/bin/du active
127
audit(1146868287.904:238): PERMITTING r access to /etc/apparmor.d
128
(du(3811) profile /usr/bin/du active /usr/bin/du)
131
If the userland auditd is not running, the kernel will send audit events
132
to klogd; klogd will send the messages to syslog, which will log the
133
messages with the KERN facility. Thus, REJECTING and PERMITTING messages
134
may go to either F</var/log/audit/audit.log> or F</var/log/messages>,
135
depending upon local configuration.
141
=item F</etc/init.d/apparmor>
143
=item F</etc/apparmor.d/>
145
=item F</var/lib/apparmor/>
147
=item F</var/log/audit/audit.log>
149
=item F</var/log/messages>
155
apparmor_parser(8), aa_change_hat(2), apparmor.d(5),
156
subdomain.conf(5), aa-autodep(1), clean(1),
158
aa-unconfined(8), aa-enforce(1), aa-complain(1), and
159
L<http://wiki.apparmor.net>.