[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Colin Walters]

On Thu, Apr 16, 2015, at 02:23 PM, Lennart Poettering wrote:
>
> Now, to put together a more complex scenario for you: consider a small
> web UI that can be used to set the system time. It should realy run at
> minimal privileges, after all it has a surface to the web. Hence you
> write it as daemon, make it run as a user id of its own, set up a
> chroot() or a file system namespace, but you do keep CAP_SYS_TIME and
> a bus connection open. With that setup the web daemon can pretty much
> only set the system clock, and if it exploited cannot be used for much
> else. It will not have access to /dev/rtc, due to the file system
> namespace, but it can nicely set the system clock via timedated still,
> and pretty much only that, and the clock will be synced to the RTC by
> it.

I'm uncertain about the value of this, particularly over the alternative
of having systemd (or polkit) do uid -> privilege mapping.  The latter
is a lot more flexible and allows the calling process fewer privileges -
they can only talk to the bus.  Saying that a filesystem namespace
will drop out /dev/rtc as a way to avoid the calling process being
able to actually make *use* of its CAP_SYS_TIME for the hardware
outside of the bus call feels like a bit of a hack.

Now that said quite a while ago I did file:
https://bugs.freedesktop.org/show_bug.cgi?id=35623
which is the inverse of this whole discussion.  It looks
like systemd already uses CAP_SYS_ADMIN as the generic
fallback, but nothing using polkit can do this today.  Retaining
the capability-reading code to determine CAP_SYS_ADMIN
feels to me like a nice-to-have, but we really do also want
daemons to run as non-root anyways.

(I have only briefly scanned the systemd bus privilege code and
 very little of the kdbus code so take the above for what it's worth)