[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140320144739.14dcf53c@alan.etchedpixels.co.uk>
Date: Thu, 20 Mar 2014 14:47:39 +0000
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Kees Cook <keescook@...omium.org>
Cc: "Theodore Ts'o" <tytso@....edu>,
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
> Capabilities can be seen as related to this patch set, but it cannot
> be seen as a blocker. This logic is needed today, it's implemented,
> and it clearly marks where the known problems are. If an overhaul of
> capabilities happens, it can happen separately.
A working version is needed today - but the implementation assumes things
like the idea you can blacklist a few boot parameters and all is good. The
reality is the reverse. So this at the moment is security theatre at
least for the EFI and PC case.
At the minimum you need to do module and kernel command line parameter
whitelisting/signing.
It's also rather odd to suggest the solution is to splatter changes all
over the kernel causing mass churn and maintainer headache... so that we
can do the whole mass churn again fixing what was added.
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/
Powered by blists - more mailing lists