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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
