On Thu, May 31, 2012 at 6:22 PM, Gregory Maxwell <gmaxw...@gmail.com> wrote: > On Thu, May 31, 2012 at 12:11 PM, Gerry Reno <gr...@verizon.net> wrote: > On Thu, May 31, 2012 at 12:13 PM, Miloslav Trmač <m...@volny.cz> wrote: >> That is just untrue. SecureBoot can be used to make sure you only run >> the software you intended to run, which is impossible without >> SecureBoot (e.g. this cannot be done with a TPM). The idea is solid, > > I don't think this is fair. > > SecureBoot doesn't protect you from someone with access to the > hardware (they can disable secureboot). BIOS passwords. (Yes, it can be reset on many machines, but that's a property of the machine, not of the design.)
> And if your kernel is secure > than userspace malware can also not change your boot environment. > If your kernel is _not_ secure then the malware will just modify the > first piece of unsigned userspace code (e.g. systemd) so that it > executes the kernel exploit at startup before updates have a chance to > run, and the kernel rootkit will prevent the updates. Right, you have to sign or otherwise authenticate (e.g. dm-verity) a lot. > So unless you take the route of signing everything (with the according > loss of software freedom, and a lot of runtime overhead) this actually > doesn't buy you a lot. I can't see that this is a freedom issue. You are absolutely not _forced_ to use the system this way. You can use a hardware and software combination in this more secure way with Secure Boot, and it is not possible without Secure Boot, but you as the owner of the hardware are fully in control. The hardware owner's ability to completely disable Secure Boot enforcement in the firmware means that he has exactly the same freedom as when using hardware or software that does not support Secure Boot. AFAICS, this is, overall, purely a convenience issue - but I may be missing something. > Microsoft's competitive advantage is that they lose little by locking > down everything and will potentially get more security as a result. > Fedora's pas competitive advantage was that it provided its users with > the freedom to change the whole system with low friction— something > MSFT's business model can't allow. By playing along we legitimize > their advantages and weaken our own. And in practice, since we won't > accept a full lock down (nor, hopefully would the licenses permit it), > Fedora will mostly not enjoy the security benefit. Well, Fedora will enjoy a different security benefit by removing the user-space ability to manipulate DMA, even for users that don't have SecureBoot-capable hardware. If you don't want to "play along", don't buy hardware that defaults to enforcing SecureBoot. That has probably more potential to change the situation than Fedora not signing its releases, anyway. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
