[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[David Herrmann]

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.

Thanks
David