• Network Access Control
• The
SYS_PTRACE
Capability
• Directory Path Access
The current version of AppArmor mediates file locking and introduces a new permission
mode (
k
) for this. Applications requesting file locking permission might misbehave or
fail altogether if confined by older profiles which do not explicitly contain permissions
to lock files. If you suspect this being the case, check the log file under
/var/log/
audit/audit.log
for entries like the following:
type=APPARMOR_DENIED msg=audit(1188913493.299:9304): operation="file_lock"
requested_mask="k" denied_mask="k" name="/home/tux/.qt/.qtrc.lock" pid=25736
profile="/usr/bin/opera"
Update the profile using the YaST Update Profile Wizard or the
aa-logprof
com-
mand as outlined below.
The new network access control syntax based on the network family and type specifi-
cation, described in
Section 2.1.1, “Network Access Control”
(page 14), might cause
application misbehavior or even stop applications from working. If you notice a network-
related application behaving strangely, check the log file under
/var/log/audit/
audit.log
for entries like the following:
type=APPARMOR_DENIED msg=audit(1188894313.206:9123): operation="socket_create"
family="inet" sock_type="raw" protocol=1 pid=23810 profile="/bin/ping"
This log entry means that our example application,
/bin/ping
in this case, failed to
get AppArmor's permission to open a network connection. This permission has to be
explicitly stated to make sure that an application has network access. To update the
profile to the new syntax, use the YaST Update Profile Wizard or the
aa-logprof
command as outlined below.
The current kernel requires the
SYS_PTRACE
capability, if a process tries to access
files in
/proc/
pid
/fd/*
. New profiles need an entry for the file and the capability
where old profiles only needed the file entry. For example:
/proc/*/fd/** rw,
in the old syntax would translate to the following rules in the new syntax:
capability SYS_PTRACE,
/proc/*/fd/** rw,
Support
119
