On Thursday, September 7, 2017 at 9:15:31 AM UTC-4, cooloutac wrote: > On Tuesday, August 29, 2017 at 1:09:36 PM UTC-4, Leo Gaspard wrote: > > On 08/29/2017 04:01 PM, cooloutac wrote: > > > On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote: > > >> Just encrypting /boot would bring little, as it would still be possible > > >> to modify the unencrypted part of GRUB (that decrypts /boot) to have it > > >> overwrite the /boot with malicious kernel images (or even to not use the > > >> ones provided). > > >> > > >> The options I know of are (from IMO strongest to weakest): > > >> * AEM, for knowing when someone tampered with /boot > > >> * SecureBoot, for restricting the allowed-to-boot images (I don't know > > >> about its ease of use with qubes, though) > > >> * locking your bootloader with a password and disallow external boot > > >> > > >> I'd think having all these protections at the same time would be best, > > >> using secureboot mostly to avoid having to ditch the laptop after AEM > > >> says it's no longer trustworthy (because it may stop the attacker before > > >> it can even make the laptop no longer trustworthy). > > > > > > secureboot can do more then restricting boot images, it can restrict > > > unsigned drivers too. Thats the part Joanna doesn't like because she > > > does not trust who will maintain the list of signed drivers. I say I'm > > > already putting just as much trust into alot of other things like my > > > banks ssl cert when connecting to my bank account. > > > > > > We are already trusting everything coming from upstream when we update... > > > > Well it can, but the issue with secureboot I remember reading about in > > the AEM post [1] is that it assumes no security vulnerability in all the > > bootchain (which could be used to trick eg. grub to run another image > > than the one you expect it to), while AEM only assumes no security > > vulnerability in the TPM. > > > > That's why I was putting secureboot forward only as a limited way to > > prevent malicious modifications, in parallel with AEM, that would still > > be used as a more secure way of checking secureboot worked correctly. > > > > [1] https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html > > well after hacking teams bios exploit was said to be stopped by secure boot > it became a big target last year. there has been a couple exploits for > windows, which have all been patched. But None of them relate to linux at > all. Although nothing is 100%, nor will there ever be.
I believe the one exploit had to do with driver test signing in win10, another was leaked keys. Neither would affect a linux secure boot. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/967af6a4-edee-436b-98ec-c817a6380292%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
