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?
David Lang
--
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
