On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny <mgo...@gentoo.org> wrote:
> On Sun, 17 Jun 2012 11:20:38 +0200 > Florian Philipp <li...@binarywings.net> wrote: > > > Am 16.06.2012 19:51, schrieb Michał Górny: > > > On Fri, 15 Jun 2012 09:54:12 +0200 > > > Florian Philipp <li...@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
