[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Andy Lutomirski]

On Thu, Apr 16, 2015 at 10:43 AM, Tom Gundersen <teg at jklm.no> wrote:
> On Thu, Apr 16, 2015 at 5:57 PM, Andy Lutomirski <luto at amacapital.net> wrote:
>>> We have several uses of this, see my mail to Jiri regarding
>>> CAP_SYS_BOOT for instance:
>>>   https://lkml.org/lkml/2015/4/16/219
>>
>> I read that, but I disagree with you.
>>
>> CAP_SYS_BOOT is the privilege to directly hard-reboot the system, not
>> the privilege to initiate a clean reboot.
>
> My main point that being allowed to do a hard-reboot, but not to do a
> clean reboot, makes no sense.
>
>>> However, what we are trying to get to the bottom of is if you see any
>>> technical problems with the current kdbus capability handling code. My
>>> understanding is that you don't.
>>>
>>
>> I have a technical problem with it: it's a design that has
>> insufficient justification.  It also seems like it will be quite
>> limiting in the future, *especially* wrt user namespaces.
>
> What I was really asking was if you see any actual vulnerabilities.
> That we have a different technical opinion on the design of this is a
> different matter.
>
>> I agree that it's probably not exploitable *if used carefully* in the
>> latest kdbus code.
>
> 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.

--Andy