[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Andy Lutomirski]

On Thu, Apr 16, 2015 at 9:43 AM, Tom Gundersen <teg at jklm.no> wrote:
> On Thu, Apr 16, 2015 at 4:52 PM, Andy Lutomirski <luto at amacapital.net> wrote:
>> Unshare your user namespace, set things up right, and systemd
>> or any other server will see you as having all capabilities.  You've
>> fixed that in kdbus, but you haven't (and probably can't!) fix it in
>> the legacy code, and that legacy code is still there (!).
>
> The dbus1 code (which I assume you mean when you say "legacy code")
> does not make use of capabilities, and it should not (see Lennart's
> answer for all the details). If anything, this should be an argument
> to move to kdbus with native, race-free capability-passing support.
>
> Do I understand correctly, that any concerns you had are about systemd
> and its dbus1 compat code (which of course we should take seriously
> too), and that you no longer see any security vulnerabilities in the
> capability related code of kdbus?
>
>> The ratio of complexity of capability code the kdbus folks have
>> already written (hundreds of lines across multiple files) to its
>> utility (very near zero AFAICT) is, in my book, not a good sign at
>> all.
>
> 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.

Keep in mind that, on some recent Windows versions, for the most part
you *can't* directly hard-reboot the system; instead you have to give
the OS a reason so the OS can log it.  IOW, the high-level Windows
reboot permission doesn't confer the privilege of directly
hard-rebooting.

Maybe systemd or GNOME will want to do that some day.

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

I agree that it's probably not exploitable *if used carefully* in the
latest kdbus code.

--Andy