Message-ID: <CAAMvbhEpmgE3badW0e7p4X4aeZwRd5Md3_5Q+g2s8r3p7dm5+w@mail.gmail.com>
Date:	Thu, 8 Nov 2012 10:18:04 +0000
From:	James Courtier-Dutton <james.dutton@...il.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Olivier Galibert <galibert@...ox.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Florian Weimer <fw@...eb.enyo.de>,
	Chris Friesen <chris.friesen@...band.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Pavel Machek <pavel@....cz>,
	Eric Paris <eparis@...isplace.org>,
	Jiri Kosina <jkosina@...e.cz>, Oliver Neukum <oneukum@...e.de>,
	Josh Boyer <jwboyer@...il.com>,
	LKML Mailing List <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [RFC] Second attempt at kernel secure boot support

Hi,

The basis for any secure boot is a way to detect that the system has
been tampered with or not. "Tamper Evidence".
There are two main vectors for a system to be tampered with. Someone
local to the machine and remote users who can access the machine
across a network interface. (this includes the local user installing a
program from a remote source)
You have a fair chance of protecting via physical means (Locked rooms,
Background checks on users etc.) of preventing a user with malicious
intent to access the local machine.
The first thing a computer does when switched on is run its first code
instructions. Commonly referred to as the BIOS.
It would therefore be a requirement to ensure that the BIOS cannot be
tampered with via any other method apart from physically located at
the machine. Once you have a base computer code that cannot be
tampered with, you can trust it.
>From that point on, you can use digital signatures to build the chain of trust.
Normally digital signatures would examine the binary, ensure the
signature matches, and then run the code contained in it.
It is vital that the private key used to sign binaries cannot be found
on the local machine, otherwise an malicious user could use it to sign
malicious code, and therefore break the trust.
The binary files therefore must be signed on a separate computer, that
is trusted and protected from malicious users.
There is one known use case where the normal digital signature checks
will not work and this is the Hibernate file.
The files were digitally checked when loaded into a previously running machine.
The state of the machine was then saved to a file.
The problem is how to check the hibernate file has not been tampered
with in the interim.
As explained above, we cannot store a private key on the local
machine, so some other method for checking that the hibernate file has
not been tampered with is required.
I would suggest the fix for this problem is working out a way to check
the signature of binary files, while in RAM, or even on a running
machine. This is the format that the hibernate file is, it is
basically a RAM image.
When starting a hibernate image, the file would have to be scanned and
digital signature checked that all the executable code in the
hibernate image was sourced from correctly digitally signed binaries.

In fact, this last point, if done correctly, could replace virus
scanners. We would then have a system that rather than scan for
viruses, it instead scans for "tampering".

Remaining problems:
1) deciding who you trust, and from that, which digital
signatures/certificates you trust.
2) Handling compromised or expired signatures/certificates.

For 2, if the signatures are attached in each binary file, in order to
distribute a new set of signatures, you would have to re-distribute
all the binary files. Not a good idea due to download size. I would
therefore suggest that the signatures are distributed separately from
the binary files, so that you can change the signatures without having
to redistribute all the binary files.

Summary:
1) The BIOS code and the certificate it uses to check subsequently
loaded binaries should only be changeable by a user local to the
machine or not changeable at all without changing hardware.

For example, on some ARM based mobile phones, the BIOS and certificate
it uses are in a ROM, so not changeable at all. It then uses a multi
stage boot loader, with each stage providing for a different
certificate to be used to the next stage. This then permits the
certificates that are used to sign the Linux kernel to be changed
without having to change the certificate in the ROM. For Secure boot
for Linux, the BIOS and certificate should probably be controlled by
the user who controls the physical access to his machine. Then multi
stage boot loaders can be used to introduce a chain to trust to trust
other certificates, such as the debian or redhat or Microsoft ones, if
the user chooses to trust them.
With the user using their own BIOS certificate, it is very unlikely
for the remote malicious user to obtain the private key and thus
compromise the security of the system.

2) When "tamper" is detected, the system should revert to a stable
safe state. This probably means, prevent the system booting, and
present the local user with the evidence of tampering. Letting the
user choose the next step.

On 7 November 2012 14:55, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote:
>> On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett <mjg59@...f.ucam.org>wrote:
>>
>> > Sure, and scripts run as root can wipe your files too. That's really not
>> > what this is all about.
>>
>> What it is about then? What is secure boot supposed to do for the owner of
>> the computer in a linux context?  I've not been able to understand it
>> through this discussion.
>
> It provides a chain of trust that allows you to ensure that a platform
> boots a trusted kernel. That's a pre-requisite for implementing any kind
> of fully trusted platform, but it's not sufficient in itself. One of
> those additional requirements is ensuring that the kernel *stays*
> trusted - in the past an attacker could just replace the kernel on disk
> and so there was little incentive to engage in more subtle attacks, but
> now that's impossible we need to care about them.
>
> --
> Matthew Garrett | mjg59@...f.ucam.org
> --
> 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/
--
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