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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 9 Sep 2013 13:10:26 -0700 (PDT)
From:	David Lang <david@...g.hm>
To:	Josh Boyer <jwboyer@...il.com>
cc:	"H. Peter Anvin" <hpa@...or.com>,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Kees Cook <keescook@...omium.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	James Morris <jmorris@...ei.org>,
	linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 00/12] One more attempt at useful kernel lockdown

On Mon, 9 Sep 2013, Josh Boyer wrote:

> On Mon, Sep 9, 2013 at 3:41 PM, H. Peter Anvin <hpa@...or.com> wrote:
>> On 09/09/2013 12:01 PM, Valdis.Kletnieks@...edu wrote:
>>> On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said:
>>>
>>>> Given that we know that people want signed binaries without
>>>> blocking kexec, you should have '1' just enforce module signing
>>>> and '2' (or higher) implement a full lockdown including kexec.
>>>
>>>> Or, eliminate the -1  permanently insecure option and make this a
>>>> bitmask, if someone wants to enable every possible lockdown, have
>>>> them set it to "all 1's", define the bits only as you need them.
>>>
>>> This strikes me as much more workable than one big sledgehammer.
>>>
>>
>> I.e. capabilities ;)
>
> Circles.  All I see here are circles.

the thing is that these are not circles. they are separate orthoginal things 
that you may or may not want to allow.

If this was a simple set of circles, then this could be defined as a vector 
instead of bitmap, the further you go the more secure you are.

But there are always going to be cases where you want to keep most of the 
lockdown, but relax just one specific aspect of it, so you want it to be a 
bitmap instead nested circles.

Now, I know that some people are going to argue that if you relax one portion 
you have a hole in your secureity so it's not worth having any security at all. 
but I've been doing security for banks for the last 16 years and I can say that 
security is not a binary thing, just because there is one hole it isn't 
worthless to close another one. Attackers are not omnificent, they don't know 
everything there is to know about your system. If you block some holes you will 
make those attaches worthless. some holes you need to leave open to avoid 
breaking the business, and you either mitigate the risk in other ways (as 
discussed in this thread, by only loading modules from media that was tested to 
be intact, even if they aren't signed), or you accept that risk and factor the 
cost of cleanup into your cusiness plans.

David Lang

> Having lived an entire release with a capabilities based mechanism for
> this in Fedora, please no.
>
> And if you are talking about non-POSIX capabilities as you mentioned
> earlier, that seems to be no different than having securelevel being a
> bitmask of, well, levels.  I don't have much opinion on securelevel
> being a big hammer or a bitmask of finer grained things, but I do
> think it's a more manageable way forward.  Calling the implementation
> "capabilities" seems to just be unnecessarily confusing.
>
> josh
>
--
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/