<div class="gmail_quote">On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny <span dir="ltr"><<a href="mailto:mgorny@g.o" target="_blank">mgorny@g.o</a>></span> wrote:<br><blockquote class="gmail_quote" style="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="h5">Florian Philipp <<a href="mailto:lists@...">lists@...</a>> wrote:<br>
<br>
> Am 16.06.2012 19:51, schrieb Michał Górny:<br>
> > On Fri, 15 Jun 2012 09:54:12 +0200<br>
> > Florian Philipp <<a href="mailto:lists@...">lists@...</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 excerpted:<br>
> >>><br>
> >>>> So, anyone been thinking about this? I have, and 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 issues?<br>
> >>>><br>
> >>>> Minor details like, "do we have a 'company' 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. Other than updating the handbook to accommodate<br>
> >>> UEFI, presumably along with the grub2 stabilization, I believe<br>
> >>> we're fine as if a user can't figure out how to disable 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 Secure 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 Florian)</div><div><br></div><div>The real problem that surrounds this idea of security is that we need to make </div><div>
_a lot_ of assumptions about the code/programs we run. We _trust_ that the </div><div>code we compile is as secure as possible and does not implement any </div><div>"backdoors". If this is the case, then</div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. How does it increase security?<br></blockquote><div>This removed a few vectors of attack and ensures your computer is only</div><div>bootstrapped by and booted using software you think is safe. By using</div><div>any software we don't write, we make a lot of assumptions.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. What happens if, say, your bootloader is compromised?<br></blockquote><div>Same thing that would happen if the bootloader was compromised today. </div><div>We currently rely on trusting the maintainer, code review, community review, etc.</div>
<div>Perhaps these efforts will need to be doubled now that any weak-link could </div><div>compromise the system.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. What happens if the machine signing the blobs is compromised?<br></blockquote><div>See above. But also, a compromised system wouldn't necessarily mean the</div><div>blobs would be compromised as well. In addition, ideally 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 that UEFI will lock down a system to </div><div>prevent a compromise from occurring, it's the fact that it reduces the areas of attack </div>
<div>and/or makes the attacks extremely difficult to accomplish. This just adds more </div><div>protection in hardware for kernel-space that SELinux, apparmor, etc provide for userspace.</div><div><br></div><div>- Matt</div>
</div>
|
