AppArmor confinement is provided via profiles loaded into the kernel via apparmor_parser(8), typically through the /etc/init.d/apparmor SysV initscript, which is used like this:
# /etc/init.d/apparmor start # /etc/init.d/apparmor stop # /etc/init.d/apparmor restart
AppArmor can operate in two modes: enforcement, and complain or learning:
Profiles are traditionally stored in files in /etc/apparmor.d/ under filenames with the convention of replacing the / in pathnames with . (except for the root /) so profiles are easier to manage (e.g. the /usr/sbin/nscd profile would be named usr.sbin.nscd).
Profiles are applied to a process at exec(3) time (as seen through the execve(2) system call); an already running process cannot be confined. However, once a profile is loaded for a program, that program will be confined on the next exec(3).
AppArmor supports the Linux kernel's securityfs filesystem, and makes available the list of the profiles currently loaded; to mount the filesystem:
# mount -tsecurityfs securityfs /sys/kernel/security $ cat /sys/kernel/security/apparmor/profiles /usr/bin/mutt /usr/bin/gpg ...
Normally, the initscript will mount securityfs if it has not already been done.
AppArmor also restricts what privileged operations a confined process may execute, even if the process is running as root. A confined process cannot call the following system calls:
create_module(2) delete_module(2) init_module(2) ioperm(2) iopl(2) mount(2) umount(2) ptrace(2) reboot(2) setdomainname(2) sethostname(2) swapoff(2) swapon(2) sysctl(2)
A confined process can not call mknod(2) to create character or block devices.
audit(1148420912.879:96): REJECTING x access to /bin/uname (sh(6646) profile /tmp/sh active /tmp/sh) audit(1148420912.879:97): REJECTING r access to /bin/uname (sh(6646) profile /tmp/sh active /tmp/sh) audit(1148420944.837:98): REJECTING access to capability 'dac_override' (sh(6641) profile /tmp/sh active /tmp/sh)
The permissions requested by the process are immediately after REJECTING. The ``name'' and process id of the running program are reported, as well as the profile name and any ``hat'' that may be active. (``Name'' is in quotes, because the process name is limited to 15 bytes; it is the same as reported through the Berkeley process accounting.) If no hat is active (see change_hat(2)) then the profile name is printed for ``active''.
For confined processes running under a profile that has been loaded in complain mode, enforcement will not take place and the log messages reported to audit will be of the form:
audit(1146868287.904:237): PERMITTING r access to /etc/apparmor.d/tunables (du(3811) profile /usr/bin/du active /usr/bin/du) audit(1146868287.904:238): PERMITTING r access to /etc/apparmor.d (du(3811) profile /usr/bin/du active /usr/bin/du)
If the userland auditd is not running, the kernel will send audit events to klogd; klogd will send the messages to syslog, which will log the messages with the KERN facility. Thus, REJECTING and PERMITTING messages may go to either /var/log/audit/audit.log or /var/log/messages, depending upon local configuration.