From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: [RFC] Second attempt at kernel secure boot support Date: Wed, 31 Oct 2012 17:08:20 +0000 Message-ID: <20121031170820.2b26802a@pyramind.ukuu.org.uk> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121031155635.GA14294-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Matthew Garrett Cc: Josh Boyer , Jiri Kosina , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-efi@vger.kernel.org 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) From mboxrd@z Thu Jan 1 00:00:00 1970 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 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)