[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Lennart Poettering]

On Thu, 16.04.15 10:52, Andy Lutomirski (luto at amacapital.net) wrote:

> >
> > It would be very helpful if you could go into details on why you think
> > more care is needed here than for other things. Is there anything
> > non-trivial going on here that I'm missing? The way capabilites are
> > exposed through kdbus seems perfectly straight-forward to me, so I'm
> > really trying to get my head around your concerns here.
> >
> > So, let me ask explicitly again:
> >
> >     * Are there any actual exploitable vulnerabilities you are aware
> > of in the kdbus kernel code?
> >
> >     * Are there any actual exploitable vulnerabilities on the sd-bus
> > userspace code you are aware of, regardless if in the kdbus or dbus1
> > support in it?
> >
> > If you are, please provide us with good explanations, so that we can
> > do something about them. We'd love to fix this!
> 
> I don't see a vulnerability in the code as such.  But you still
> haven't given a real use case, and vulnerabilities in security
> mechanisms are often found in the interactions between components.
> There doesn't seem to be a big picture here.
> 
> Can you give a plausible real world example along the lines of
> "process A, which has capability B for some decent reason, will send
> message C to daemon D, and D will permit the request because of
> capability B, but the request would not otherwise have been
> permitted."
> 
> So far it seems like there's a bunch of code that may not be
> exploitable but doesn't really do anything either.
> 
> And, honestly, if this is only about rebooting and setting the time,
> then, even if correct, this is seriously not worth the complexity even
> if it's completely sensible and correct.

Well, you asked for examples, I gave you two simple, existing
ones. 

Note that the caps-based method authorization is not much used
currently, especially not outside of systemd, because it's not safely
doable on dbus1, but only on kdbus, and kdbus is not merged into the
kernel yet, hence not many projects use it yet.

But anyway, here are two more example in systemd itself:

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).

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.

And if you are not happy with this example, there are numerous others
like this of course...

Lennart

-- 
Lennart Poettering, Red Hat