Mediate auto-activation attempts through AppArmor
authorSimon McVittie <simon.mcvittie@collabora.co.uk>
Mon, 21 Nov 2016 20:45:45 +0000 (20:45 +0000)
committerSimon McVittie <simon.mcvittie@collabora.co.uk>
Mon, 28 Nov 2016 12:11:45 +0000 (12:11 +0000)
commitdc25979ebb205c4e1596f084fbcd5f78ceca864c
treeb053f8fa8dd0163f6c562eec7b6c8fb323d17e68
parent373cc47c7c50adb1b624526cfa452d52954621a5
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
bus/activation.c
bus/activation.h
bus/apparmor.c
bus/desktop-file.h