[systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[Simon McVittie]

On 09/11/14 02:08, Casey Schaufler wrote:
> Thus, dbus is a fine example where SMACK64EXEC is a bad idea. Because you
> want a system bus and a user bus with different attributes you want it to get
> the Smack label at launch time, just like you do for UID and capability sets.

I think there's a much more fundamental reason why SMACK64EXEC would be
a bad idea for "dbus"[1], which is that dbus-daemon has not been
designed to distrust its caller and prevent privilege escalation from
its caller's privileges to its own privileges. I think an executable can
only safely be setuid, or other frameworks' equivalents of setuid
(setcap, SMACK64EXEC, etc.), if the developers of that executable are
fully aware that it is a privilege boundary in that way, and are
designing it (and choosing its library dependencies!) with that in mind.
This is not the case for dbus-daemon.

It is entirely possible (although IMO unlikely) that, by coincidence,
dbus-daemon does not currently have privilege escalations from its
caller's privileges to its own privileges; but if we introduced such a
thing (executing a command given by an environment variable, perhaps), I
would not consider that to be a regression, because we never claimed it
was suitable for that use.

This is not unique to dbus; it applies equally to any project that
releases executables.

Note that dbus-daemon --system is designed to be a different sort of
privilege boundary: it enforces differing privilege levels for
applications that connect to it via D-Bus, and we do treat holes in that
policy as security flaws. That still doesn't mean it is designed to be
suitable for setuid.

    S

[1] I assume you mean dbus-daemon, which is an executable; dbus is a
package containing dbus-daemon, some other executables, and the libdbus
library. There is no such thing as /usr/bin/dbus.