fdo-mirrors/dbus
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/dbus/dbus.git synced 2026-02-21 18:00:36 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Spec: document AppArmor mediation of auto-starting

Browse source 
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
This commit is contained in:
Simon McVittie 2016-11-22 11:39:07 +00:00
parent 025c5dc5d5
commit 457f79c262
1 changed files with 77 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

77
doc/dbus-specification.xml
View file

@ -5201,6 +5201,83 @@
service is started by systemd during boot.
</para>
</sect3>
<sect3 id="message-bus-starting-services-apparmor">
<title>Mediating Activation with AppArmor</title>
<para>
Please refer to
<ulink url="http://wiki.apparmor.net/index.php/Documentation">AppArmor documentation</ulink>
for general information on AppArmor, and how it mediates D-Bus
messages when used in conjunction with a kernel and
<literal>dbus-daemon</literal> that support this.
</para>
<para>
In recent versions of the reference <literal>dbus-daemon</literal>,
AppArmor policy rules of type <literal>dbus send</literal>
are also used to control auto-starting: if a message is sent to
the well-known name of an activatable service, the
<literal>dbus-daemon</literal> will attempt to determine whether
it would deliver the message to that service
<emphasis>before</emphasis>auto-starting it, by making some
assumptions about the resulting process's credentials.
</para>
<para>
If it does proceed with auto-starting, when the service appears, the
<literal>dbus-daemon</literal> repeats the policy check (with
the service's true credentials, which might not be identical)
before delivering the message. In practice, this second check will
usually be more strict than the first; the first check would only
be more strict if there are "blacklist"-style rules like
<literal>deny dbus send peer=(label=/usr/bin/protected)</literal>
that match on the peer's specific credentials, but AppArmor is
normally used in a "whitelist" style where this does not apply.
</para>
<para>
To support this process, service description files may contain a
<literal>AssumedAppArmorLabel</literal> key. Its value is the name
of an AppArmor label, for example
<literal>/usr/sbin/mydaemon</literal>.
If present, AppArmor mediation of messages that auto-start a
service will decide whether to allow auto-starting to occur based
on the assumption that the activated service will be confined
under the specified label; in particular, rules of the form
<literal>dbus send peer=(label=/usr/sbin/mydaemon)</literal> or
<literal>deny dbus send peer=(label=/usr/sbin/mydaemon)</literal>
will match it, allowing or denying as appropriate
(even if there is in fact no profile of that name loaded).
</para>
<para>
Otherwise, AppArmor mediation of messages that auto-start a
service will decide whether to allow auto-starting to occur
without specifying any particular label. In particular, any rule of
the form <literal>dbus send peer=(label=X)</literal> or
<literal>deny dbus send peer=(label=X)</literal>
(for any value of X, including the special label
<literal>unconfined</literal>) will not influence whether the
auto-start is allowed.
</para>
<para>
Rules of type <literal>dbus receive</literal> are not checked
when deciding whether to allow auto-starting; they are only checked
against the service's profile after the service has started, when
deciding whether to deliver the message that caused the auto-starting
operation.
</para>
<para>
Explicit activation via
<xref linkend="bus-messages-start-service-by-name"/> is not currently
affected by this mediation: if a confined process is to be prevented
from starting arbitrary services, then it must not be allowed to call
that method.
</para>
</sect3>
</sect2>
<sect2 id="message-bus-types">