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
On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote:
On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett mj...@srcf.ucam.orgwrote:
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
On Wed, 31 Oct 2012, Matthew Garrett wrote:
Reading stored memory image (potentially tampered before reboot) from disk
is basically DMA-ing arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this could be made secure (without
storing private keys to
On Tue, Nov 06, 2012 at 01:51:15PM +0100, Jiri Kosina wrote:
On Wed, 31 Oct 2012, Matthew Garrett wrote:
shim generates a public and private key.
It seems to me that this brings quite a huge delay into the boot process
both for regular and resume cases (as shim has no way to know what is
On Tue, Nov 06, 2012 at 09:12:17AM +, Alan Cox wrote:
- is it worth Red Hat doing - that's up to Red Hat's business managers
- is it worth merging into the kernel - that's not
The capability bit is small and clean the rest of it is beginning to look
far too ugly for upstream right now.
On 11/06/2012 01:56 AM, Florian Weimer wrote:
Personally, I think the only way out of this mess is to teach users
how to disable Secure Boot.
If you're going to go that far, why not just get them to install a
RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead?
Secure boot
On Tue, 06 Nov 2012 16:55:25 -0500
Matthew Garrett mj...@srcf.ucam.org wrote:
I'm not sure why you think that Fedora PXE installs will automatically wipe
disks - they'll do whatever Kickstart tells them to do. The only thing
relevant to secure boot here is that you need a signed bootloader,
Sure, and scripts run as root can wipe your files too. That's really not what
this is all about.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Sun, 2012-11-04 at 13:52 +, Matthew Garrett wrote:
On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote:
I've actually had more than enough experience with automated installs
over my career: they're either done by paying someone or using a
provisioning system. In either
On Mon, 5 Nov 2012 12:38:58 +
Matthew Garrett mj...@srcf.ucam.org wrote:
On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote:
H. Peter Anvin h...@zytor.com writes:
That is a hugely different thing from needing a console.
Not at all.
In the general case user
On Sun, 4 Nov 2012, Eric W. Biederman wrote:
Why is when kernel has been securely booted, the in-kernel kexec
mechanism has to verify the signature of the supplied image before
kexecing it not enough? (basically the same thing we are doing for signed
modules already).
For modules
On Mon, 5 Nov 2012, Jiri Kosina wrote:
Do I understand you correctly that by the 'glue' stuff you actually mean
the division of the kexec image into segments?
Of course, when we are dividing the image into segments and then passing
those individually (even more so if some transformations
* James Bottomley:
Right, but what I'm telling you is that by deciding to allow automatic
first boot, you're causing the windows attack vector problem. You could
easily do a present user test only on first boot which would eliminate
it.
Apparently, the warning will look like this:
Matthew Garrett mj...@srcf.ucam.org writes:
On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote:
Matthew Garrett mj...@srcf.ucam.org writes:
No, in the general case the system will do that once it fails to find a
bootable OS on the drive.
In the general case there will be
On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote:
Matthew Garrett mj...@srcf.ucam.org writes:
On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote:
Matthew Garrett mj...@srcf.ucam.org writes:
No, in the general case the system will do that once it fails to
Matthew Garrett mj...@srcf.ucam.org writes:
On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote:
Matthew Garrett mj...@srcf.ucam.org writes:
On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote:
Matthew Garrett mj...@srcf.ucam.org writes:
No, in the general
On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote:
For automated installs you don't have to satisfy me. Feel free to
deliver a lousy solution to your users. Just don't use your arbitrary
design decisions to justify your kernel patches.
My kernel patches are justified by
On Mon, Nov 05, 2012 at 09:19:46PM -0800, Eric W. Biederman wrote:
Matthew Garrett mj...@srcf.ucam.org writes:
On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote:
For automated installs you don't have to satisfy me. Feel free to
deliver a lousy solution to your users.
On Sun 2012-11-04 04:28:02, Matthew Garrett wrote:
On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote:
On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote:
I... what? Our signed bootloader will boot our signed kernel without any
physically present end-user involvement.
Matthew Garrett mj...@srcf.ucam.org writes:
On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote:
I've actually had more than enough experience with automated installs
over my career: they're either done by paying someone or using a
provisioning system. In either case, they
Jiri Kosina jkos...@suse.cz writes:
On Fri, 2 Nov 2012, Vivek Goyal wrote:
With secure boot enabled, then the kernel should refuse to let an
unsigned kexec load new images, and kexec itself should refuse to
load unsigned images.
Yep, good in theory. Now that basically means
On 11/05/2012 07:14 AM, Eric W. Biederman wrote:
In any case the notion that unattended install with no user interaction
on any uefi machine in any state is complete and total rubbish. It
can't be done. You need power and you need boot media.
That is a hugely different thing from needing
H. Peter Anvin h...@zytor.com writes:
On 11/05/2012 07:14 AM, Eric W. Biederman wrote:
In any case the notion that unattended install with no user interaction
on any uefi machine in any state is complete and total rubbish. It
can't be done. You need power and you need boot media.
That
You're guaranteed to be able
to do this on any Windows 8 certified hardware.
Thats not my understanding of the situation.
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Fri, Nov 02, 2012 at 05:22:41PM +0100, Jiri Kosina wrote:
On Fri, 2 Nov 2012, Vivek Goyal wrote:
crash utility has module which allows reading kernel memory. So
leaking
this private key will be easier then you are thinking it to be.
That's not upstream, right?
Yes,
Matthew Garrett mj...@srcf.ucam.org writes:
On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote:
When the goal is to secure Linux I don't see how any of this helps.
Windows 8 compromises are already available so if we turn most of these
arguments around I am certain clever
On 11/02/2012 04:03 PM, Eric W. Biederman wrote:
Matthew Garrettmj...@srcf.ucam.org writes:
On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote:
When the goal is to secure Linux I don't see how any of this helps.
Windows 8 compromises are already available so if we turn most
No reason to? How can I configure an off the shelf system originally
sold with windows 8 installed to boot in UEFI secure boot mode using
shim without trusting Microsoft's key?
Assuming its an x86 and a PC class platform and thus should allow you to
disable secure boot mode then you disable
On Fri, Nov 02, 2012 at 05:47:02PM -0700, Eric W. Biederman wrote:
No reason to? How can I configure an off the shelf system originally
sold with windows 8 installed to boot in UEFI secure boot mode using
shim without trusting Microsoft's key?
Delete the installed keys, install your choice
On Thu, 2012-11-01 at 10:20 +0100, Jiri Kosina wrote:
On Thu, 1 Nov 2012, James Bottomley wrote:
The point I'm making is that given that the majority of exploits will
already be able to execute arbitrary code in-kernel, there's not much
point trying to consider features like this as
I think it make sense because the private key is still protected by
signer. Any hacker who modified firmware is still need use private key
to generate signature, but hacker's private key is impossible to match
with the public key that kernel used to verify firmware.
And, I afraid we have no
On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
But that doesn't really help me: untrusted root is an oxymoron.
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty
On Thu, Nov 1, 2012 at 10:46 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Imagine you run windows and you've never heard of Linux.
To those people I think you mean never heard of Ubuntu ;-)
:-)
With all the current posted RH patches I can still take over
the box as root trivially enough and
would get keys revoked. If your key is revoke Linux can't boot on a
large amount of new hardware without BIOS twiddling.
See live free or die. If you want to live in a world where you can't
even fart before checking if the man from Microsoft will revoke your key
you might as well go home now.
On Thu, Nov 01, 2012 at 03:06:30PM +, James Bottomley wrote:
But surely that's fanciful ... you've already compromised windows to get
access to the ESP. If you've done it once, you can do it again until
the exploit is patched. There are likely many easier ways of ensuring
persistence
On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote:
On Thu, Nov 1, 2012 at 11:18 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
You're completely confusing two separate goals:
1. Is it possible to use secure boot to implement a security policy
on Linux
On Thu, Nov 01, 2012 at 09:03:20PM +, James Bottomley wrote:
On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote:
What do we have to do to prevent Linux being used to attack Linux
which may lead to secure boot being useless.
That's not really remotely related, is it? Microsoft doesn't
On Mon, 29 Oct 2012, Matthew Garrett wrote:
This is pretty much identical to the first patchset, but with the
capability
renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone
wants
to deploy these then they should disable kexec until support for signed
kexec
is basically DMA-ing arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this could be made secure (without
storing private keys to sign the hibernation image on the machine itself
which, well, doesn't sound secure either).
That's what the TPM is for (in
On Wed, 31 Oct 2012, Alan Cox wrote:
All this depends on your threat model. If I have physical access to
suspend/resume your machine then you already lost. If I don't have
physical access then I can't boot my unsigned OS to patch your S4 image
so it doesn't matter.
Prepare (as a root) a
On Wed, Oct 31, 2012 at 05:03:34PM +, Alan Cox wrote:
On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
Jiri Kosina jkos...@suse.cz wrote:
Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
from that artificial image.
It's not signed. It won't reboot from that image.
The
41 matches
Mail list logo
