From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965112AbaCTOsE (ORCPT ); Thu, 20 Mar 2014 10:48:04 -0400 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:43599 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933379AbaCTOr7 (ORCPT ); Thu, 20 Mar 2014 10:47:59 -0400 Date: Thu, 20 Mar 2014 14:47:39 +0000 From: One Thousand Gnomes To: Kees Cook Cc: "Theodore Ts'o" , Matthew Garrett , "linux-kernel@vger.kernel.org" , "jmorris@namei.org" , "linux-security-module@vger.kernel.org" , "akpm@linux-foundation.org" , "hpa@zytor.com" , "jwboyer@fedoraproject.org" , "linux-efi@vger.kernel.org" , "gregkh@linuxfoundation.org" Subject: Re: Trusted kernel patchset for Secure Boot lockdown Message-ID: <20140320144739.14dcf53c@alan.etchedpixels.co.uk> In-Reply-To: References: <1394746248.27846.3.camel@x230> <20140313232140.03bdaac3@alan.etchedpixels.co.uk> <1394762250.6416.24.camel@x230.lan> <20140314122231.17b9ca8a@alan.etchedpixels.co.uk> <1394801518.6416.38.camel@x230.lan> <20140314170655.0ce398a3@alan.etchedpixels.co.uk> <1394820664.26846.18.camel@x230.mview.int.nebula.com> <20140314214806.54a3d031@alan.etchedpixels.co.uk> <1394834193.1286.11.camel@x230> <20140314220840.29a12171@alan.etchedpixels.co.uk> <20140314231832.GA653@thunk.org> Organization: Intel Corporation X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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