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

[WaLyong Cho]

On 11/10/2014 08:57 PM, Simon McVittie wrote:
> 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.
> 
Ah..dbus-daemon was just a example as a well known daemon. Actually,
this problem was occurred on email-service daemon. Currently, that has
"system::email" SMACK label. Please forgot I'd mentioned about
dbus-daemon. Currently, we are using daemon-daemon with "_" label like
other system daemon.

I wonder about other guys also confused about this.

Thanks
WaLyong

> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>