Re: [PATCH] x86: Lock down MSR writing in secure boot

From: Josh Boyer
Date: Fri Feb 08 2013 - 16:14:14 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/