Hi On Fri, Apr 17, 2015 at 5:52 PM, 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. > > 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
