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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Sep 2013 12:59:50 -0700 (PDT)
From:	David Lang <david@...g.hm>
To:	Matthew Garrett <matthew.garrett@...ula.com>
cc:	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 00/12] One more attempt at useful kernel lockdown

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/