From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-52636-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1SgIoo-0007nn-EB
for garchives@archives.gentoo.org; Sun, 17 Jun 2012 16:59:21 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id D48EAE07C8;
Sun, 17 Jun 2012 16:58:39 +0000 (UTC)
Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53])
by pigeon.gentoo.org (Postfix) with ESMTP id 8A9AEE07C0
for <gentoo-dev@lists.gentoo.org>; Sun, 17 Jun 2012 16:56:56 +0000 (UTC)
Received: by vbbfc26 with SMTP id fc26so2726822vbb.40
for <gentoo-dev@lists.gentoo.org>; Sun, 17 Jun 2012 09:56:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type;
bh=kBHJzRNpSqGgslyz189ZnBAMP51LiljximYpm/7HhTM=;
b=sjp2dOtqI5K/thrXyEd96/qMEheGJpY8MnnD6nTx3a4z7OeMrlEqjHRPhhm/yM8ic+
xX4EgI3AY1j6L9d5Ri6QmdMyjTm041eTaTiTHww0IEGvapR5tL/vBEntwiAjPc8LxW/L
+pDPzlhDCqbXND0sedRYMDEQ5u14exUyOz6KuQpG+NVjAFTcFxT+qlJQ1YlUT3+PKNX+
8GKUzoXUXWfWVpgIQcNYd4QoCXFBMP7ke+z05g4So5+QbfY19KlII7JeqZ3cUWT2WsQ+
CrXtuqLofxI/JJ9qkyrQM6s+N4nmaLOrn32zEL1Bfp/vhNGGvRHroProadvhtrG9VlS/
w9VQ==
Received: by 10.52.23.144 with SMTP id m16mr5274333vdf.77.1339952216071; Sun,
17 Jun 2012 09:56:56 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.52.171.228 with HTTP; Sun, 17 Jun 2012 09:56:34 -0700 (PDT)
In-Reply-To: <20120617175104.055e62e8@pomiocik.lan>
References: <20120615042810.GA9480@kroah.com> <pan.2012.06.15.04.50.46@cox.net>
<4FDAEA24.3010303@binarywings.net> <20120616195104.192e5abd@pomiocik.lan>
<4FDDA166.8010404@binarywings.net> <20120617175104.055e62e8@pomiocik.lan>
From: Matthew Finkel <matthew.finkel@gmail.com>
Date: Sun, 17 Jun 2012 12:56:34 -0400
Message-ID: <CAGF8hssozZN8D9TxzWLA5E=xuEG2vri_J-i9UyeLoAba8YpY0g@mail.gmail.com>
Subject: Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
To: gentoo-dev@lists.gentoo.org
Content-Type: multipart/alternative; boundary=20cf307c9dacdadefe04c2adef7d
X-Archives-Salt: abefd9b1-41f1-4c95-bd43-21d4e5758772
X-Archives-Hash: 2a6ab2fe51215b7ba8605fe5ab54c3a1
--20cf307c9dacdadefe04c2adef7d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Jun 17, 2012 at 11:51 AM, Micha=C5=82 G=C3=B3rny <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=C5=82 G=C3=B3rny:
> > > 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
--20cf307c9dacdadefe04c2adef7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Sun, Jun 17, 2012 at 11:51 AM, Micha=C5=82 G=
=C3=B3rny <span dir=3D"ltr"><<a href=3D"mailto:mgorny@gentoo.org" target=
=3D"_blank">mgorny@gentoo.org</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
On Sun, 17 Jun 2012 11:20:38 +0200<br>
<div><div class=3D"h5">Florian Philipp <<a href=3D"mailto:lists@binarywi=
ngs.net">lists@binarywings.net</a>> wrote:<br>
<br>
> Am 16.06.2012 19:51, schrieb Micha=C5=82 G=C3=B3rny:<br>
> > On Fri, 15 Jun 2012 09:54:12 +0200<br>
> > Florian Philipp <<a href=3D"mailto:lists@binarywings.net">list=
s@binarywings.net</a>> wrote:<br>
> ><br>
> >> Am 15.06.2012 06:50, schrieb Duncan:<br>
> >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as exce=
rpted:<br>
> >>><br>
> >>>> So, anyone been thinking about this? =C2=A0I have, an=
d it's not<br>
> >>>> pretty.<br>
> >>>><br>
> >>>> Should I worry about this and how it affects Gentoo, =
or not worry<br>
> >>>> about Gentoo right now and just focus on the other is=
sues?<br>
> >>>><br>
> >>>> Minor details like, "do we have a 'company&#=
39; that can pay<br>
> >>>> Microsoft to sign our bootloader?" is one aspect=
from the<br>
> >>>> non-technical side that I've been wondering about=
.<br>
> >>><br>
> >>> I've been following developments and wondering a bit =
about this<br>
> >>> myself.<br>
> >>><br>
> >>> I had concluded that at least for x86/amd64, where MS is =
mandating<br>
> >>> a user controlled disable-signed-checking option, gentoo =
shouldn't<br>
> >>> have a problem. =C2=A0Other than updating the handbook to=
accommodate<br>
> >>> UEFI, presumably along with the grub2 stabilization, I be=
lieve<br>
> >>> we're fine as if a user can't figure out how to d=
isable that<br>
> >>> option on their (x86/amd64) platform, they're hardly =
likely to be<br>
> >>> a good match for gentoo in any case.<br>
> >>><br>
> >><br>
> >> As a user, I'd still like to have the chance of using Sec=
ure Boot<br>
> >> with Gentoo since it _really_ increases security. Even if it =
means<br>
> >> I can no longer build my own kernel.<br>
> ><br>
> > It doesn't. It's just a very long wooden fence; you just =
didn't find<br>
> > the hole yet.<br>
> ><br>
><br>
> Oh come on! That's FUD and you know it. If not, did you even look =
at<br>
> the specs and working principle?<br>
<br>
</div></div>Could you answer the following question:<br></blockquote><div>(=
Sorry to jump in on this=C2=A0Florian)</div><div><br></div><div>The real pr=
oblem that surrounds this idea of security is that we need to make=C2=A0</d=
iv><div>
_a lot_ of assumptions about the code/programs we run. We _trust_ that the=
=C2=A0</div><div>code we compile is as secure as possible and does not impl=
ement any=C2=A0</div><div>"backdoors". If this is the case, then<=
/div><div>
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
1. How does it increase security?<br></blockquote><div>This removed a few v=
ectors of attack and ensures your computer is only</div><div>bootstrapped b=
y and booted using software you think is safe. By using</div><div>any softw=
are we don't write, we make a lot of assumptions.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
2. What happens if, say, your bootloader is compromised?<br></blockquote><d=
iv>Same thing that would happen if the bootloader was compromised today.=C2=
=A0</div><div>We currently rely on trusting the maintainer, code review, co=
mmunity review, etc.</div>
<div>Perhaps these efforts will need to be doubled now that any weak-link c=
ould=C2=A0</div><div>compromise the system.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
3. What happens if the machine signing the blobs is compromised?<br></block=
quote><div>See above. But also, a compromised system wouldn't necessari=
ly mean the</div><div>blobs would be compromised as well. In addition, idea=
lly the priv-key would</div>
<div>be kept isolated to ensure a compromise would be extremely difficult.<=
/div><div><br></div><div>My understanding is that it's not the case tha=
t UEFI will lock down a system to=C2=A0</div><div>prevent a compromise=C2=
=A0from occurring, it's the fact that it reduces the areas of attack=C2=
=A0</div>
<div>and/or makes=C2=A0the attacks extremely difficult to accomplish. This =
just adds more=C2=A0</div><div>protection in hardware=C2=A0for kernel-space=
that SELinux, apparmor, etc provide for userspace.</div><div><br></div><di=
v>- Matt</div>
</div>
--20cf307c9dacdadefe04c2adef7d--