Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753461Ab2JaRDT (ORCPT ); Wed, 31 Oct 2012 13:03:19 -0400 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:33421 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750992Ab2JaRDR (ORCPT ); Wed, 31 Oct 2012 13:03:17 -0400 Date: Wed, 31 Oct 2012 17:08:20 +0000 From: Alan Cox To: Matthew Garrett Cc: Josh Boyer , Jiri Kosina , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-efi@vger.kernel.org Subject: Re: [RFC] Second attempt at kernel secure boot support Message-ID: <20121031170820.2b26802a@pyramind.ukuu.org.uk> In-Reply-To: <20121031155635.GA14294@srcf.ucam.org> References: <1348152065-31353-1-git-send-email-mjg@redhat.com> <20121029174131.GC7580@srcf.ucam.org> <20121031155503.1aaf4c93@pyramind.ukuu.org.uk> <20121031155635.GA14294@srcf.ucam.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII= 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 Content-Length: 1199 Lines: 30 On Wed, 31 Oct 2012 15:56:35 +0000 Matthew Garrett wrote: > 1) Gain root. > 2) Modify swap partition directly. > 3) Force reboot. > 4) Win. > > Root should not have the ability to elevate themselves to running > arbitrary kernel code. Therefore, the above attack needs to be > impossible. To protect swap you need to basically disallow any unencrypted swap (as he OS can't prove any given swap device is local and inside the case) and disallow the use of most disk management tools (so you'll need to write a few new management interfaces or implement the BPF based command filters that have been discussed for years). In addition of course there is no requirement that a device returns the data you put on it so subverted removable media is a potential issue. Or indeed just cheap memory sticks that do it anyway ;) Oh and of course the file systems in default mode don't guarantee this so you'll need to fix ext3, ext4 8) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/