On Thu, 16.04.15 12:30, Andy Lutomirski (l...@amacapital.net) wrote: > > systemd itself checks CAP_SYS_KILL for clients asking to kill > > arbitrary services (which means invoking kill() to all PIDs in the > > service's cgroup). > > > > Similar to this, logind checks CAP_SYS_KILL for clients asking to kill > > sessions (which means invoking kill() for all PIDS in the session). > > > > These aren't the kinds of examples I'm asking about. They're what > systemd does, not what use case makes doing that serve a purpose.. > > > 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. > > Aha, a real example! > > But this is a bad example -- systemd should provide the web server > with a way to retain the right to issue the one method call that it > needs. CAP_SYS_TIME is overbroad.
systemd or kdbus are not about inventing a completely new authorization schemes. I mean, there are a thousand ways to lock things down. You can also use SELinux or AppArmor here. But you can also use caps. And caps are actually pretty nice for this, since a good scheme for a daemon like this might be to first try the bus service if it is around, and as a fallback go directly to the kernel. in that scheme it could then support systemd and non-systemd systems, with pretty much the same effect, without shipping things with completely different policies. > For example, CAP_SYS_TIME also > grants the service to bypass whatever auditing and logging systemd > would do. Sure, you can always argue that capabilities are broad, and that something more fine-grained would be better. And I will absolutely agree with you on this. However, this is not about comparing caps with seccomp or selinux or something like this. It's about granting that web ui daemon full root privs with uid=0 vs. just CAP_SYS_TIME. And yes, just requiring the cap is a ton safer than requiring full uid=0. And that's where the core of the issue is! I mean, yes, locking things down as much as possible is a great thing. We can stack seccomp, apparmor, selinux, namespacing, uid droppping all at the same time and then we have the safest system ever. However, that doesn't relieve us from also saying that "yes, caps are mor minimal than uid=0", and hence supporting caps instead of just uid=0 as privilege indication. > And this is also a worthless design pattern, as it seems to be > applicable to sending signals and changing the time, and probably very > little else. Well, an accounting daemon that opens up acct() calls could use CAP_SYS_PACCT. Some debugging daemon that opens up controleld access to /dev/kmem or so, could use CAP_SYS_RAWIO... systemd itself could probably bind the resource management controls to CAP_SYS_REOURCE. Networkd can require CAP_NET_ADMIN for its config commands, and so on. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel