2
0
mirror of https://gitlab.com/apparmor/apparmor synced 2025-09-03 15:55:46 +00:00

can ?not fix apparmor.pod

At least that's how this patch started ;-)

The updated (and much bigger) patch
- removes the note about can ?not mknod
- also removes mount and umount from the can ?not list which are covered
  by mount rules now
- updates the example audit.log lines to the current log format
- updates the description of the log format

Acked-By: Seth Arnold <seth.arnold@canonical.com> (on IRC)

Seth also promised a follow-up patch with the remaining changes.
This commit is contained in:
Christian Boltz
2013-12-12 03:07:37 +01:00
parent f0cfec62cd
commit d60f1a19da

View File

@@ -6,6 +6,9 @@
# Copyright (c) 2010 # Copyright (c) 2010
# Canonical Ltd. (All rights reserved) # Canonical Ltd. (All rights reserved)
# #
# Copyright (c) 2013
# Christian Boltz (All rights reserved)
#
# This program is free software; you can redistribute it and/or # This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public # modify it under the terms of version 2 of the GNU General Public
# License published by the Free Software Foundation. # License published by the Free Software Foundation.
@@ -89,43 +92,46 @@ may execute, even if the process is running as root. A confined process
cannot call the following system calls: cannot call the following system calls:
create_module(2) delete_module(2) init_module(2) ioperm(2) create_module(2) delete_module(2) init_module(2) ioperm(2)
iopl(2) mount(2) umount(2) ptrace(2) reboot(2) setdomainname(2) iopl(2) ptrace(2) reboot(2) setdomainname(2)
sethostname(2) swapoff(2) swapon(2) sysctl(2) sethostname(2) swapoff(2) swapon(2) sysctl(2)
A confined process can not call mknod(2) to create character or block devices.
=head1 ERRORS =head1 ERRORS
When a confined process tries to access a file it does not have permission When a confined process tries to access a file it does not have permission
to access, the kernel will report a message through audit, similar to: to access, the kernel will report a message through audit, similar to:
audit(1148420912.879:96): REJECTING x access to /bin/uname audit(1386511672.612:238): apparmor="DENIED" operation="exec"
(sh(6646) profile /tmp/sh active /tmp/sh) parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
audit(1148420912.879:97): REJECTING r access to /bin/uname audit(1386511672.613:239): apparmor="DENIED" operation="open"
(sh(6646) profile /tmp/sh active /tmp/sh) parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
audit(1148420944.837:98): REJECTING access to capability audit(1386511772.804:246): apparmor="DENIED" operation="capable"
'dac_override' (sh(6641) profile /tmp/sh active /tmp/sh) parent=7246 profile="/tmp/sh" pid=7589 comm="sh" pid=7589
comm="sh" capability=2 capname="dac_override"
The permissions requested by the process are described in the operation=
The permissions requested by the process are immediately after and denied_mask= (for files - capabilities etc. use a slightly different
REJECTING. The "name" and process id of the running program are reported, log format).
as well as the profile name and any "hat" that may be active. ("Name" The "name" and process id of the running program are reported,
as well as the profile name including any "hat" that may be active,
separated by "//". ("Name"
is in quotes, because the process name is limited to 15 bytes; it is the 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 same as reported through the Berkeley process accounting.)
active (see aa_change_hat(2)) then the profile name is printed for "active".
For confined processes running under a profile that has been loaded in For confined processes running under a profile that has been loaded in
complain mode, enforcement will not take place and the log messages complain mode, enforcement will not take place and the log messages
reported to audit will be of the form: reported to audit will be of the form:
audit(1146868287.904:237): PERMITTING r access to audit(1386512577.017:275): apparmor="ALLOWED" operation="open"
/etc/apparmor.d/tunables (du(3811) profile /usr/bin/du active parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
/usr/bin/du) pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit(1146868287.904:238): PERMITTING r access to /etc/apparmor.d audit(1386512577.017:276): apparmor="ALLOWED" operation="open"
(du(3811) profile /usr/bin/du active /usr/bin/du) parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
If the userland auditd is not running, the kernel will send audit events If the userland auditd is not running, the kernel will send audit events