On 02/08/2013 01:02 PM, Kees Cook wrote: > On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett > <matthew.garrett@xxxxxxxxxx> wrote: >> On Fri, 2013-02-08 at 12:28 -0800, Kees Cook wrote: >> >>> Maybe a capability isn't the right way to go, I'm not sure. I'll leave >>> that to Matthew. Whatever the flag, it should be an immutable state of >>> the boot. Though, it probably makes sense as a cap just so that >>> non-secure-boot systems can still remove it from containers, etc. >> >> There was interest in ensuring that this wasn't something special-cased >> to UEFI Secure Boot, so using a capability seemed like the most >> straightforward way - it's fundamentally a restriction on what an >> otherwise privileged user is able to do, so it seemed like it fit the >> model. But I'm not wed to it in the slightest, and in fact it causes >> problems for some userspace (anything that drops all capabilities >> suddenly finds itself unable to do something that it expects to be able >> to do), so if anyone has any suggestions for a better approach… > > 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. > Caps are fine; the problem is the "putting it all under one cap". The semi-problem here is that to preserve backwards compatibility we really should have a way to have hierarchical caps in Linux (which we currently don't), but it is not really an issue for this. Also, keep in mind that there is a very simple way to deny MSR access completely, which is to not include the driver in your kernel (and not allow module loading, but if you can load modules you can just load a module to muck with whatever MSR you want.) I am still wondering if there are any legitimate uses of CAP_RAWIO & ~CAP_COMPROMISE_KERNEL that can't be used to subvert the latter. I am not sure there are. -hpa -- 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
