On Fri, 17.04.15 08:52, Josh Triplett (j...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel