On Fri, Feb 8, 2013 at 4:07 PM, Matthew Garrett <matthew.garrett@xxxxxxxxxx> wrote: > On Fri, 2013-02-08 at 13:02 -0800, Kees Cook wrote: > >> I don't find it unreasonable to drop all caps and lose access to >> sensitive things. :) That's sort of the point, really. I think a cap >> is the best match. It seems like it should either be a cap or a >> namespace flag, but the latter seems messy. > > Yeah, I think it's an expected outcome, but it means that if (say) qemu > drops privileges, qemu can no longer access PCI resources - even on > non-secure boot systems. That breaks existing userspace. Right. We've had a few reports in Fedora of things breaking on non-SB systems because of this. The qemu one is the latest, but the general problem is people think dropping all caps blindly is making their apps safer. Then they find they can't do things they could do before the new cap was added. It's messy. I've thought of treating CAP_COMPROMISE_KERNEL as a hidden cap, where only the kernel can grant or drop it. Peter Jones suggested it might work to allow it to be dropped iff it is the only cap being changed. Either way, it's a "special" cap and I have no idea how acceptable something like that would be. Really though, the main issue is that you cannot introduce new caps to enforce finer grained access without breaking something. josh -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
