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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel