On Thu, Apr 16, 2015 at 9:43 AM, Tom Gundersen <t...@jklm.no> wrote: > On Thu, Apr 16, 2015 at 4:52 PM, Andy Lutomirski <l...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
