Re: [PATCH 00/12] One more attempt at useful kernel lockdown

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux