On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 11:53 -0700, David Lang wrote:
So is there a way to unify these different things rather than creating yet
another different knob?
We haven't found one that people consider generally acceptable.
At least you should be able to unify the implementation, even if you don't unify
the user visible knob
If you do this with a capabilities approach, then you can implement the 'only
load signed modules' bit and then have that bit call the existing kernel code,
or change that existing kernel code to internally set the capabilities bit.
I see you looking for two key things
1. a sledgehammer to say "I want to be as secure as possible"
2. no way to unset the setting (barring kernel bugs/vulnerabilities)
implementing this as capabilities will still let you meet your goals, just have
your tools that lock things down set the value to -1 (all 1's)
As long as a bit cannot be unset, only set, it still satisfies your second
requirement to not be able to back out.
And for people who want a partial lockdown, the various capabilities bits allow
them to get the amount of lockdown that they want.
but if you are really trying to lock down a system, there are things that you
want to do that will break normal users (things like disabling all module
loading, disabling mounting of filesystems, disable the connection of new USB
devices, etc)
These are good tools to have available, but since using them will break some
normal use cases, you really do want to be able to enable some things without
enabling others.
What you are seeing in this discussion is that even for the set of things that
you consider 'essential' to lock down, other people see valid cases to not lock
them down.
If your tools only set 'known' or 'allocated' bits, you run the risk of not
locking things down as tightly as you could, but if new bits are only allocated
for new lockdown features, this is not a regression since you are no worse off
than you would have been with an old kernel.
Since we are not talking POSIX capabilities here, we are talking 'secure the
system from even root' capabilities, there is no other system that we need to
copy. The BSD securelevel approach is a simple big hammer approach, and it's
easy to emulate with capabilities.
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
