[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Josh Triplett]

On April 20, 2015 8:39:33 AM PDT, Lennart Poettering <lennart at poettering.net> wrote:
>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.

I'd certainly agree that uid 0 checks are a bad idea, since as little code should run as root as possible. However, rather than handing out capabilities that allow bypassing systemd and talking directly to the kernel, it seems preferable to run unprivileged and grant the necessary permissions to that process.