On Mon, Sep 9, 2013 at 4:19 PM, David Lang <david@xxxxxxx> wrote: > On Mon, 9 Sep 2013, Matthew Garrett wrote: > >> On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote: >> >>> 1 lock down modules >>> 2 lock down kexec >> >> >> Having thought about this, the answer is no. It presents exactly the >> same problem as capabilities do - the set can never be meaningfully >> extended. If an application sets only the bits it knows about, and if a >> new security-sensitive feature is added to the kernel, the feature will >> be left enabled and the system will be insecure. Alternatively, if an >> application sets all the bits regardless of whether it knows them or >> not, it may enable a lockdown feature that it otherwise required. > > > In this case you are no less secure than you were before the feature was > added, you just can't take advantage of the new feature without updating > userspace. > > That's a very common situation > > >> The only way this is useful is if all the bits are semantically >> equivalent, and in that case there's no point in having anything other >> than a single bit. Users who want a more fine-grained interface should >> use one of the existing mechanisms for doing so - leave the kernel open >> and impose the security policy from userspace using either capabilities >> or selinux. > > > so if you only have a single bit, how do you deal with the case where that > bit locks down something that's required? (your reason for not just setting > all bits in the first approach) > > your arguments don't seem self consistent. > > > why should there only be one way to lock down a system? there are lots of > different use cases. > > If I'm building a kiosk PC (or voting machine), I want to disable a lot of > things that I could not get away with disabling on a generic laptop. Are we > going to have Securelevel, ReallySecurelevel, ReallyReallySecurelevel, etc? > or can we accept that security is not binary and allow users to disable > features in a more granualar way? > > And if SELinux can do the job, what is the reason for creating this new > option? Not everyone uses SELinux. :) Also, it's rarely controlled the things we want to control here. -Kees -- Kees Cook Chrome OS Security -- 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
