[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Josh Triplett]

On Thu, Apr 16, 2015 at 08:23:45PM +0200, 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.
> 
> To map this back to your earlier request for an example. In this case
> process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message
> C is the SetTime() bus call. Daemon D is timedated. 
> 
> If the web UI daemon would not have CAP_SYS_TIME it couldn't change
> the time like this -- unless of course that web UI daemon would run as
> UID 0 all the time, which is certainly much much less desirable, given
> that it is a network facing daemon.

I agree with your statement that any process with the ability to do an
operation directly (bypassing systemd) should have the ability to do so
safely through systemd.  However, that doesn't provide a complete
solution, because the reverse shouldn't necessarily be true: it should
be possible to grant a process the ability to do an operation safely
through systemd *without* granting it permission to do so directly.

For instance, a user's desktop session should have permission to shut
down the system politely by asking systemd to shut down, without having
permission to shut down the system impolitely by invoking the reboot
system call.  Or in your time service example, the admin may want to
grant the web service permission to set the clock via timedated, but
*not* directly via settimeofday.

(I'm assuming below that you agree there should be a mechanism to offer
privileges to do a safe operation but *not* the corresponding unsafe
operation.  If you don't agree, let's talk about that first.)

Given that, some mechanism needs to exist to grant the
safe-but-not-unsafe permissions.  That might be polkit, or something
like dbus bus policies, or some other mechanism.

Now, I can still see the value in saying "if you have permission to do
the unsafe thing directly, you can do the safe thing".  However, that
seems like an optional enhancement, rather than core required
functionality to make sane use of (k)dbus.  kdbus without the
capability-passing mechanism still seems like a wildly useful
enhancement.

Based on that, I'm wondering if there's any fundamental reason not to
split that out as a separate patch, get the remaining less-controversial
parts of kdbus merged, and then make the case for that separately.  Then
kdbus would be available for everyone to use sooner, and later on it
could gain some additional features.

- Josh Triplett