On Thu, Apr 16, 2015 at 5:57 PM, Andy Lutomirski <l...@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!
Cheers,
Tom
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
