On Thu, Apr 16, 2015, at 02:23 PM, 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.
I'm uncertain about the value of this, particularly over the alternative of having systemd (or polkit) do uid -> privilege mapping. The latter is a lot more flexible and allows the calling process fewer privileges - they can only talk to the bus. Saying that a filesystem namespace will drop out /dev/rtc as a way to avoid the calling process being able to actually make *use* of its CAP_SYS_TIME for the hardware outside of the bus call feels like a bit of a hack. Now that said quite a while ago I did file: https://bugs.freedesktop.org/show_bug.cgi?id=35623 which is the inverse of this whole discussion. It looks like systemd already uses CAP_SYS_ADMIN as the generic fallback, but nothing using polkit can do this today. Retaining the capability-reading code to determine CAP_SYS_ADMIN feels to me like a nice-to-have, but we really do also want daemons to run as non-root anyways. (I have only briefly scanned the systemd bus privilege code and very little of the kdbus code so take the above for what it's worth) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
