[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[josh at joshtriplett.org]

On Fri, Apr 17, 2015 at 06:00:04PM +0200, David Herrmann wrote:
> Hi
> 
> On Fri, Apr 17, 2015 at 5:52 PM, 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.
> >
> > 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.
> 
> This is _exactly_ what we do whenever it's a reasonable choice.

Glad to hear that.  With that mechanism in place, then, is the
capability-based check really necessary?  It's a nice convenience, that
avoids needing to explicitly use the new mechanism to grant permission
to an already privileged process, but it doesn't seem necessary.

Would it be that much of an imposition to push kdbus without capability
capturing first, and then argue for kdbus with capability capturing
later as a convenience feature?  As far as I can tell, that mechanism
can be added in a backward-compatible way, with older kernels just not
supporting it.

- Josh Triplett