* AppArmor no longer mediates access to AF_UNIX socket files
* Confined applications can currently read from and write to any AF_UNIX
socket files
* Existing AppArmor profiles that contain file rules granting write access to
AF_UNIX socket files are effectively being ignored
* Differences between the old, out-of-tree AppArmor kernel patches and the
patches incorporated into mainline in 2.6.36 were the cause of this
regression
* For Ubuntu, 10.04 LTS and all newer, supported releases are affected. Other
releases, which are no longer supported, may have also been affected. I was
able to verify that 8.04 LTS was not affected.
[Test Case]
* Confining dbus-send and sending a message to the system bus is an easy
manual testing method. Load a profile for dbus-send:
* Note that the system_bus_socket rule is commented out. Now, run dbus-send
under strace and see if the connect() fails. Here's the unexpected output,
taken from an Ubuntu Saucy system:
* Here's the expected output, taken from an 8.04 LTS system:
$ strace -e connect -- \
dbus-send --system --dest=org.freedesktop.DBus \
/org/freedesktop/DBus org.freedesktop.DBus.ListNames
connect(3, {sa_family=AF_FILE, path="/var/run/dbus/system_bus_socket"}, 33) = -1 EACCES (Permission denied)
Failed to open connection to system message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied
* I'll also attach a patch to the AppArmor regression test suite
[Regression Potential]
* Profiles developed with affected kernels aren't likely to have the necessary
rules because the proper LSM hook was not implemented in those kernels, so
the policy writer didn't need to grant access to AF_UNIX socket files
* The profiles shipped with AppArmor can, and will, be updated to grant access
to AF_UNIX socket files, but local policy modifications cannot be addressed
by upstream/distros. Once updated kernels begin enforcing mediation of
AF_UNIX socket files, rules in local profiles may no longer be sufficient,
resulting in new AppArmor denials for AF_UNIX socket files.
[Impact]
* AppArmor no longer mediates access to AF_UNIX socket files
* Confined applications can currently read from and write to any AF_UNIX
socket files
* Existing AppArmor profiles that contain file rules granting write access to
AF_UNIX socket files are effectively being ignored
* Differences between the old, out-of-tree AppArmor kernel patches and the
patches incorporated into mainline in 2.6.36 were the cause of this
regression
* For Ubuntu, 10.04 LTS and all newer, supported releases are affected. Other
releases, which are no longer supported, may have also been affected. I was
able to verify that 8.04 LTS was not affected.
[Test Case]
* Confining dbus-send and sending a message to the system bus is an easy
manual testing method. Load a profile for dbus-send:
$ cat << EOF | sudo apparmor_parser -r
#include <tunables/global>
/usr/bin/dbus-send { bin/dbus- send r, dbus/system_ bus_socket w,
#include <abstractions/base>
/usr/
# /var/run/
}
EOF
* Note that the system_bus_socket rule is commented out. Now, run dbus-send
under strace and see if the connect() fails. Here's the unexpected output,
taken from an Ubuntu Saucy system:
$ strace -e connect -- \ org.freedesktop .DBus \ op/DBus org.freedesktop .DBus.ListNames AF_LOCAL, sun_path= "/var/run/ dbus/system_ bus_socket" }, 33) = 0
dbus-send --system --dest=
/org/freedeskt
connect(3, {sa_family=
+++ exited with 0 +++
* Here's the expected output, taken from an 8.04 LTS system:
$ strace -e connect -- \ org.freedesktop .DBus \ op/DBus org.freedesktop .DBus.ListNames var/run/ dbus/system_ bus_socket" }, 33) = -1 EACCES (Permission denied) dbus/system_ bus_socket: Permission denied
dbus-send --system --dest=
/org/freedeskt
connect(3, {sa_family=AF_FILE, path="/
Failed to open connection to system message bus: Failed to connect to socket /var/run/
* I'll also attach a patch to the AppArmor regression test suite
[Regression Potential]
* Profiles developed with affected kernels aren't likely to have the necessary
rules because the proper LSM hook was not implemented in those kernels, so
the policy writer didn't need to grant access to AF_UNIX socket files
* The profiles shipped with AppArmor can, and will, be updated to grant access
to AF_UNIX socket files, but local policy modifications cannot be addressed
by upstream/distros. Once updated kernels begin enforcing mediation of
AF_UNIX socket files, rules in local profiles may no longer be sufficient,
resulting in new AppArmor denials for AF_UNIX socket files.