Mediation of processes sending and receiving messages

When an AppArmor confined process wants to send or receive a message, a
check is performed to see if the action should be allowed.

When a message is going through dbus-daemon, there are two checks
performed at once. One for the sending process and one for the receiving
process.

The checks are based on the process's label, the bus type, destination,
path, interface, and member, as well as the peer's label and/or
destination name.

This allows for the traditional connection-based enforcement, as well as
any fine-grained filtering desired by the system administrator.

It is important to note that error and method_return messages are
allowed to cut down on the amount of rules needed. If a process was
allowed to send a message, it can receive error and method_return
messages.

An example AppArmor rule that would be needed to allow a process to call
the UpdateActivationEnvironment method of the session bus itself would be:

  dbus send bus=session path=/org/freedesktop/DBus
       interface=org.freedesktop.DBus member=UpdateActivationEnvironment
       peer=(name=org.freedesktop.DBus),

To receive any message on the system bus from a process confined by
the "confined-client" AppArmor profile:

  dbus receive bus=system peer=(label=confined-client),

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: John Johansen <john.johansen@canonical.com>
[tyhicks: Use BusAppArmorConfinement, bug fixes, cleanup, commit msg]
[tyhicks: Pass the message type to the AppArmor hook]
[tyhicks: Don't audit unrequested reply message denials]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
[smcv: when AA denies sending, don't label requested_reply as "matched rules"]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>

0 files changed, 0 insertions, 0 deletions