[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Lennart Poettering]

On Fri, 17.04.15 08:52, Josh Triplett (josh at joshtriplett.org) wrote:

> 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.

yeah, for that side we have polkit.

> 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.

Well, sure, I mean, the caps stuff are *not* essential to kdbus' mode
of operation. But I do believe they make the system better, and should
be used preferably over broad uid == 0 checks.

Lennart

-- 
Lennart Poettering, Red Hat