linux-kernel - Re: Trusted kernel patchset for Secure Boot 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]

Message-ID: <20140314162831.1caf342c@alan.etchedpixels.co.uk>
Date:	Fri, 14 Mar 2014 16:28:31 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Kees Cook <keescook@...omium.org>
Cc:	Matthew Garrett <matthew.garrett@...ula.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"jwboyer@...oraproject.org" <jwboyer@...oraproject.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: Trusted kernel patchset for Secure Boot lockdown

> The command line problem here is a total red herring. If you've got a
> measured kernel, you have a measured command line. (If not, you don't

That would be the sensible approach, but it has some quite drastic
ramifications.

> have a measured kernel.) Dealing with the command line has nothing to
> do with enforcing the ring0/uid0 boundary which is what this patch
> series does.

It has a huge relevance. You are signing blocks of code and loading them
into your kernel. In case it's escaped your notice those blocks of code
have behaviour which is considerably customisable by passing module
arguments to them. In many cases they don't actually check those
arguments. If I can set module paramters I already 0wn your box so many
different ways its not even funny.

> Right. As mentioned, we've been over all of this before. We cannot
> change the meaning of capabilities (nor expand their coverage to
> existing interfaces) without breaking userspace. Since we cannot break
> userspace, we must create a different policy system that covers this
> new thing we want to do and keeps the new policy distinctly separate.

So you have everything checked twice all over the kernel and you
guarantee that people will get it wrong. I don't see the point of putting
a broken implementation in the kernel. If you want to do security do it
*right* and do it once. You think every single person who adds a driver
is going to muddle through two interfaces (and in future no doubt more if
we don't fix it properly) and get it right each time ?

The 'breaking userspace' argument is bullshit already. The whole *point*
of the measured kernel is to break userspace. You are deliberately
breaking a pile of functionality, much of it undersirable in order to
achieve your measured system.

The only "don't break" case that matters is if the measured stuff isn't
in use. In those cases we don't need to break anything.

Alan
--
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/