[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Lennart Poettering]

On Thu, 16.04.15 12:30, Andy Lutomirski (luto at 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