public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Matthew Finkel <matthew.finkel@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Date: Sun, 17 Jun 2012 12:56:34 -0400	[thread overview]
Message-ID: <CAGF8hssozZN8D9TxzWLA5E=xuEG2vri_J-i9UyeLoAba8YpY0g@mail.gmail.com> (raw)
In-Reply-To: <20120617175104.055e62e8@pomiocik.lan>

[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]

On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 17 Jun 2012 11:20:38 +0200
> Florian Philipp <lists@binarywings.net> wrote:
>
> > Am 16.06.2012 19:51, schrieb Michał Górny:
> > > On Fri, 15 Jun 2012 09:54:12 +0200
> > > Florian Philipp <lists@binarywings.net> wrote:
> > >
> > >> Am 15.06.2012 06:50, schrieb Duncan:
> > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:
> > >>>
> > >>>> So, anyone been thinking about this?  I have, and it's not
> > >>>> pretty.
> > >>>>
> > >>>> Should I worry about this and how it affects Gentoo, or not worry
> > >>>> about Gentoo right now and just focus on the other issues?
> > >>>>
> > >>>> Minor details like, "do we have a 'company' that can pay
> > >>>> Microsoft to sign our bootloader?" is one aspect from the
> > >>>> non-technical side that I've been wondering about.
> > >>>
> > >>> I've been following developments and wondering a bit about this
> > >>> myself.
> > >>>
> > >>> I had concluded that at least for x86/amd64, where MS is mandating
> > >>> a user controlled disable-signed-checking option, gentoo shouldn't
> > >>> have a problem.  Other than updating the handbook to accommodate
> > >>> UEFI, presumably along with the grub2 stabilization, I believe
> > >>> we're fine as if a user can't figure out how to disable that
> > >>> option on their (x86/amd64) platform, they're hardly likely to be
> > >>> a good match for gentoo in any case.
> > >>>
> > >>
> > >> As a user, I'd still like to have the chance of using Secure Boot
> > >> with Gentoo since it _really_ increases security. Even if it means
> > >> I can no longer build my own kernel.
> > >
> > > It doesn't. It's just a very long wooden fence; you just didn't find
> > > the hole yet.
> > >
> >
> > Oh come on! That's FUD and you know it. If not, did you even look at
> > the specs and working principle?
>
> Could you answer the following question:
>
(Sorry to jump in on this Florian)

The real problem that surrounds this idea of security is that we need to
make
_a lot_ of assumptions about the code/programs we run. We _trust_ that the
code we compile is as secure as possible and does not implement any
"backdoors". If this is the case, then


> 1. How does it increase security?
>
This removed a few vectors of attack and ensures your computer is only
bootstrapped by and booted using software you think is safe. By using
any software we don't write, we make a lot of assumptions.

2. What happens if, say, your bootloader is compromised?
>
Same thing that would happen if the bootloader was compromised today.
We currently rely on trusting the maintainer, code review, community
review, etc.
Perhaps these efforts will need to be doubled now that any weak-link could
compromise the system.


> 3. What happens if the machine signing the blobs is compromised?
>
See above. But also, a compromised system wouldn't necessarily mean the
blobs would be compromised as well. In addition, ideally the priv-key would
be kept isolated to ensure a compromise would be extremely difficult.

My understanding is that it's not the case that UEFI will lock down a
system to
prevent a compromise from occurring, it's the fact that it reduces the
areas of attack
and/or makes the attacks extremely difficult to accomplish. This just adds
more
protection in hardware for kernel-space that SELinux, apparmor, etc provide
for userspace.

- Matt

[-- Attachment #2: Type: text/html, Size: 5094 bytes --]

  parent reply	other threads:[~2012-06-17 16:59 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15  4:28 [gentoo-dev] UEFI secure boot and Gentoo Greg KH
2012-06-15  4:45 ` Arun Raghavan
2012-06-15  4:56   ` Greg KH
2012-06-15  5:24     ` Arun Raghavan
2012-06-15 21:28       ` Matthew Thode
2012-06-15  5:48     ` Eray Aslan
2012-06-15  7:26     ` Michał Górny
2012-06-15  7:49       ` Florian Philipp
2012-06-15  8:06         ` Richard Farina
2012-06-15  8:24           ` Florian Philipp
2012-06-15 23:59         ` Greg KH
2012-06-16  8:33           ` Florian Philipp
2012-06-16  0:03       ` gregkh
2012-06-15  5:00   ` [gentoo-dev] " Duncan
2012-06-15  5:03   ` [gentoo-dev] " Ben de Groot
2012-06-15  5:08     ` Matthew Finkel
2012-06-15  5:24     ` Arun Raghavan
2012-06-15  7:12       ` Ben de Groot
2012-06-15  7:58         ` Richard Farina
2012-06-15  8:37           ` Florian Philipp
2012-06-15 11:32             ` Walter Dnes
2012-06-15 12:01               ` Rich Freeman
2012-06-15 12:48                 ` Florian Philipp
2012-06-16  9:22                 ` Maxim Kammerer
2012-06-17 17:03                   ` Greg KH
2012-06-17 19:22                     ` Maxim Kammerer
2012-06-15 10:50           ` Ben de Groot
2012-06-16  0:02     ` Greg KH
2012-06-15  4:45 ` Greg KH
2012-06-15  5:48   ` Philip Webb
2012-06-16  0:01     ` Greg KH
2012-06-16  3:18       ` Philip Webb
2012-06-15 21:35   ` Matthew Thode
2012-06-16  0:00     ` Greg KH
2012-06-15  4:50 ` [gentoo-dev] " Duncan
2012-06-15  5:01   ` Matthew Finkel
2012-06-15  7:54   ` Florian Philipp
2012-06-15 12:28     ` Walter Dnes
2012-06-15 12:55       ` Florian Philipp
2012-06-16 23:37         ` Steev Klimaszewski
2012-06-17 16:58           ` Greg KH
2012-06-17 17:24             ` Dale
2012-06-16 17:51     ` Michał Górny
2012-06-17  9:20       ` Florian Philipp
2012-06-17 15:51         ` Michał Górny
2012-06-17 16:55           ` Greg KH
2012-06-17 17:06             ` Michał Górny
2012-06-17 17:17               ` Rich Freeman
2012-06-17 17:28               ` Florian Philipp
2012-06-17 17:56               ` Greg KH
2012-06-17 16:56           ` Matthew Finkel [this message]
2012-06-17 17:10             ` Michał Górny
2012-06-17 17:40               ` Florian Philipp
2012-06-17 17:34       ` Sascha Cunz
2012-06-17 17:55         ` Rich Freeman
2012-06-17 18:00         ` Florian Philipp
2012-06-17 18:56           ` Sascha Cunz
2012-06-17 19:20             ` Graham Murray
2012-06-17 20:30             ` Florian Philipp
2012-06-17 23:07               ` Rich Freeman
2012-06-22  6:42                 ` George Prowse
2012-06-15  4:57 ` [gentoo-dev] " Chí-Thanh Christopher Nguyễn
2012-06-15 12:18   ` Luca Barbato
2012-06-15 12:33     ` Rich Freeman
2012-06-15 23:56   ` Greg KH
2012-06-16  6:30     ` Michał Górny
2012-06-15 10:14 ` Rich Freeman
2012-06-15 11:26   ` Florian Philipp
2012-06-15 12:22   ` Luca Barbato
2012-06-15 12:45     ` Rich Freeman
2012-06-15 15:46   ` G.Wolfe Woodbury
2012-06-15 23:55   ` Greg KH
2012-06-16  0:41     ` Rich Freeman
2012-06-16  3:49       ` Greg KH
2012-06-16 23:52 ` Matthew Summers
2012-06-17  0:23   ` [gentoo-dev] " Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGF8hssozZN8D9TxzWLA5E=xuEG2vri_J-i9UyeLoAba8YpY0g@mail.gmail.com' \
    --to=matthew.finkel@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox