1 |
On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny <mgorny@g.o> wrote: |
2 |
|
3 |
> On Sun, 17 Jun 2012 11:20:38 +0200 |
4 |
> Florian Philipp <lists@×××××××××××.net> wrote: |
5 |
> |
6 |
> > Am 16.06.2012 19:51, schrieb Michał Górny: |
7 |
> > > On Fri, 15 Jun 2012 09:54:12 +0200 |
8 |
> > > Florian Philipp <lists@×××××××××××.net> wrote: |
9 |
> > > |
10 |
> > >> Am 15.06.2012 06:50, schrieb Duncan: |
11 |
> > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: |
12 |
> > >>> |
13 |
> > >>>> So, anyone been thinking about this? I have, and it's not |
14 |
> > >>>> pretty. |
15 |
> > >>>> |
16 |
> > >>>> Should I worry about this and how it affects Gentoo, or not worry |
17 |
> > >>>> about Gentoo right now and just focus on the other issues? |
18 |
> > >>>> |
19 |
> > >>>> Minor details like, "do we have a 'company' that can pay |
20 |
> > >>>> Microsoft to sign our bootloader?" is one aspect from the |
21 |
> > >>>> non-technical side that I've been wondering about. |
22 |
> > >>> |
23 |
> > >>> I've been following developments and wondering a bit about this |
24 |
> > >>> myself. |
25 |
> > >>> |
26 |
> > >>> I had concluded that at least for x86/amd64, where MS is mandating |
27 |
> > >>> a user controlled disable-signed-checking option, gentoo shouldn't |
28 |
> > >>> have a problem. Other than updating the handbook to accommodate |
29 |
> > >>> UEFI, presumably along with the grub2 stabilization, I believe |
30 |
> > >>> we're fine as if a user can't figure out how to disable that |
31 |
> > >>> option on their (x86/amd64) platform, they're hardly likely to be |
32 |
> > >>> a good match for gentoo in any case. |
33 |
> > >>> |
34 |
> > >> |
35 |
> > >> As a user, I'd still like to have the chance of using Secure Boot |
36 |
> > >> with Gentoo since it _really_ increases security. Even if it means |
37 |
> > >> I can no longer build my own kernel. |
38 |
> > > |
39 |
> > > It doesn't. It's just a very long wooden fence; you just didn't find |
40 |
> > > the hole yet. |
41 |
> > > |
42 |
> > |
43 |
> > Oh come on! That's FUD and you know it. If not, did you even look at |
44 |
> > the specs and working principle? |
45 |
> |
46 |
> Could you answer the following question: |
47 |
> |
48 |
(Sorry to jump in on this Florian) |
49 |
|
50 |
The real problem that surrounds this idea of security is that we need to |
51 |
make |
52 |
_a lot_ of assumptions about the code/programs we run. We _trust_ that the |
53 |
code we compile is as secure as possible and does not implement any |
54 |
"backdoors". If this is the case, then |
55 |
|
56 |
|
57 |
> 1. How does it increase security? |
58 |
> |
59 |
This removed a few vectors of attack and ensures your computer is only |
60 |
bootstrapped by and booted using software you think is safe. By using |
61 |
any software we don't write, we make a lot of assumptions. |
62 |
|
63 |
2. What happens if, say, your bootloader is compromised? |
64 |
> |
65 |
Same thing that would happen if the bootloader was compromised today. |
66 |
We currently rely on trusting the maintainer, code review, community |
67 |
review, etc. |
68 |
Perhaps these efforts will need to be doubled now that any weak-link could |
69 |
compromise the system. |
70 |
|
71 |
|
72 |
> 3. What happens if the machine signing the blobs is compromised? |
73 |
> |
74 |
See above. But also, a compromised system wouldn't necessarily mean the |
75 |
blobs would be compromised as well. In addition, ideally the priv-key would |
76 |
be kept isolated to ensure a compromise would be extremely difficult. |
77 |
|
78 |
My understanding is that it's not the case that UEFI will lock down a |
79 |
system to |
80 |
prevent a compromise from occurring, it's the fact that it reduces the |
81 |
areas of attack |
82 |
and/or makes the attacks extremely difficult to accomplish. This just adds |
83 |
more |
84 |
protection in hardware for kernel-space that SELinux, apparmor, etc provide |
85 |
for userspace. |
86 |
|
87 |
- Matt |