Mediate auto-activation attempts through AppArmor

Because the recipient process is not yet available, we have to make some
assumption about its AppArmor profile. Parsing the first word of
the Exec value and then chasing symlinks seems like too much magic,
so I've gone for something more explicit. If the .service file contains

AssumedAppArmorLabel=/foo/bar

then we will do the AppArmor query on the assumption that the recipient
AppArmor label will be as stated. Otherwise, we will do a query
with an unspecified label, which means that AppArmor rules that do
specify a peer label will never match it.

Regardless of the result of this query, we will do an independent
AppArmor query when the activation has actually happened, this time
with the correct peer label; that second query will still be used
to decide whether to deliver the message. As a result, if this change
has any effect, it is to make the bus more restrictive; it does not
allow anything that would previously have been denied.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666

1 files changed, 1 insertions, 0 deletions

diff --git a/bus/activation.h b/bus/activation.h
index fc5d426f..7ae8ade9 100644
--- a/bus/activation.h
+++ b/bus/activation.h
@@ -64,5 +64,6 @@ dbus_bool_t    bus_activation_send_pending_auto_activation_messages (BusActivati
 								     BusService        *service,
 								     BusTransaction    *transaction);
 
+const char *bus_activation_entry_get_assumed_apparmor_label (BusActivationEntry *entry);
 
 #endif /* BUS_ACTIVATION_H */