Qubes support Secure Boot

[jonbrown...@gmail.com]

Sorry if this has been previously discussed but I have not found anything concrete. Does Qubes support UEFI Secure Boot?

Thanks

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Aug 31, 2015 at 12:45:11PM -0700, jonbrown...@gmail.com wrote:
> Sorry if this has been previously discussed but I have not found anything concrete. Does Qubes support UEFI Secure Boot?

No, it isn't supported. In fact even UEFI isn't supported yet, but we're
working on it:
https://github.com/QubesOS/qubes-issues/issues/794

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJV5LJgAAoJENuP0xzK19csrkEH/jJyV+QU+1JGEN8Zg6ZpK2ON
Ytdkudexxbop6Heu9mMOdc7Xc86+KuuD5W+a0VBoOycgbTChFIFuEhK6WiMGGruV
ZNB61jTj9y8nMSzecjAyvCQX7pIHIEcx5Xu/ePOJU3I8NgcGr41aX+IIRWkB8O0a
znYHvO5XodEPn3KI4dMiu47t+K/MZak14Poqcar4qosLu8OB5RX+1XSiKaXakX7z
ady0tuSHHkJ1VDp8aQNKyBQcZJFykVEQ69LEllpe6dE6JTFDR5SJTn8VaX1Hh6qD
RRBBv/jan4akGL1ynzCl2nXxjnwbwYS4BFGRso4KWyplc1z6n/Lu4kZ2lAqxbpk=
=aYWf
-----END PGP SIGNATURE-----

[timet...@gmail.com]

On Monday, August 31, 2015 at 1:45:11 PM UTC-6, jonbrown...@gmail.com wrote:
> Sorry if this has been previously discussed but I have not found anything concrete. Does Qubes support UEFI Secure Boot?
>
> Thanks

A related question...

does the fact that UEFI allows for pre-os networking present any problems to the Qubes security model?

[xep...@gmail.com]

This is quite late, but now that UEFI is supported...is secure boot? Wasn't quite sure what key or signature to import.

[Tai...@gmx.com]

On 11/22/2017 07:25 PM, xep...@gmail.com wrote:

> This is quite late, but now that UEFI is supported...is secure boot? Wasn't quite sure what key or signature to import.

Why are all the newbies here so obsessed with a microsoft technology?

Just shut it off, it provides no benefit to you. If their code is so
great and beneficial to you why not simply install windows 10? they say
it is safe and secure just like SB 2.0...

"Secure" boot isn't secure, it is an anti-feature designed to eventually
remove the ability for average joes to install and boot linux - while SB
1.0 included a owner control mandate this was conveniently left out of
SB 2.0 after the SB 1.0 media circus died down with the goal being the
eventual blocking of linux via attrition of board makers no longer
wanting to take the extra effort to allow for owner control or even add
the second SB key which allows people to boot the red hat signed version
of grub2.

If you have to ask for permission to run code it isn't your computer and
you do not own it you are simply purchasing a lease on it.
I for one would never buy such a thing and neither should you (I have
re-programmed the firmware on all my workstations/servers - they are
owner controlled and are truly mine with no hardware code signing
enforcement anti-features - doesn't that sound better?)

Tell me, how does it prevent a rootkit? why couldn't that hypothetical
rootkit simply modify another critical system file instead of the
bootloader or kernel? or disable SB? (already root, hence rootkit - if
you have a zero day for windows you certainly have one for SB as well)

[Leo Gaspard]

On 11/23/2017 03:35 AM, Tai...@gmx.com wrote:
> On 11/22/2017 07:25 PM, xep...@gmail.com wrote:
>> This is quite late, but now that UEFI is supported...is secure boot? 
>> Wasn't quite sure what key or signature to import.
> Why are all the newbies here so obsessed with a microsoft technology?
>
> Just shut it off, it provides no benefit to you. If their code is so
> great and beneficial to you why not simply install windows 10? they say
> it is safe and secure just like SB 2.0...
>

> [... more of the same]

Can you please avoid ranting against secure boot once again?

Secure boot is *not* useless. It *does* bring security benefits,
although not as good as measured boot with a TPM: it requires an
additional flaw somewhere in the {BIOS, bootloader} to bypass, instead
of just coming in and replacing a non-encrypted element of the bootchain
by taking the hard disk out of its case without ever being noticed. So
if you have no TPM, using secure boot is a definitive security enhancement.

That said, to answer the original question, Qubes doesn't support secure
boot out of the box yet as far as I can tell.

[cooloutac]

why are you so obsessed with microsoft. Once again, it would have nothing to do with them. Richard Stallman admitted he was wrong. Why can't you?

[cooloutac]

My vote is to use both. Or as Intel puts it to use all three of trusted, measured, and secured boot. Enterprise systems also throw malware scanners somewhere in there during the mix.

Richard Stallman predicted secureboot would lock out software, but he was wrong. He half heartedly says "Microsoft failed their intended purpose", and Even He suggests using secure boot as a security feature now. Which is all it ever really was. MS even has option to turn off driver signing in the software. Some people, especially computer guys, have trouble admitting when they are wrong.

Nothing is 100% secured, but secure boot stopped hacking teams famous bios attack, and i'm sure theres more like it out there. And in this world where remote bios attacks are possible, thats enough for me to not call any system even reasonably secure if it doesn't have secure boot enabled.

And i've said before, Security mostly depends on the USER more then the hardware and operating system. Some user tasks are inherently unsafe no matter what and you would have to limit yourself using your own volition, regardless or hardware or software. And imo, A hardened windows system, especially if enterprise, is much safer for the AVG user then a similarly hardened linux system. (I just saw Tai's head explode)

Of course many feel Qubes is for more advanced users, and apparently that will become a self fulfilling prophecy in version 4.

[xep...@gmail.com]

Thanks for the replies. I generally dislike secure boot, and even UEFI. I was mainly asking since I couldn't find a clear answer...and if it was possible, why not do it!

Other distributions use a shim bootloader signed with a Microsoft key. It might be adventitious for QubesOS to do the same. I can't think of a major downside to it right now. It could make installation a bit easier. Some systems may not have the option for secure boot to be deactivated.

I disabled secure boot, but I'm stuck trying to get QubesOS to install. Fighting with a nmi watchdog bug soft lockup. Maybe I'll start another thread about that if I can't get it figured out.

[Andrew Eason]

Couloutac mentioned Richard Stallman's comments.  I was curious what he said, so I looked it up.

There is an addendum at the bottom to his original essay.

from the bottom of the essay at https://www.gnu.org/philosophy/can-you-trust.html

(I added a * to the most relevant line):

As of 2015, treacherous computing has been implemented for PCs in the form of the “Trusted Platform Module”; however, for practical reasons, the TPM has proved a total failure for the goal of providing a platform for remote attestation to verify Digital Restrictions Management. Thus, companies implement DRM using other methods. At present, “Trusted Platform Modules” are not being used for DRM at all, and there are reasons to think that it will not be feasible to use them for DRM. Ironically, this means that the only current uses of the “Trusted Platform Modules” are the innocent secondary uses—for instance, to verify that no one has surreptitiously changed the system in a computer.

*Therefore, we conclude that the “Trusted Platform Modules” available for PCs are not dangerous, and there is no reason not to include one in a computer or support it in system software.

This does not mean that everything is rosy. Other hardware systems for blocking the owner of a computer from changing the software in it are in use in some ARM PCs as well as processors in portable phones, cars, TVs and other devices, and these are fully as bad as we expected.

This also does not mean that remote attestation is harmless. If ever a device succeeds in implementing that, it will be a grave threat to users' freedom. The current “Trusted Platform Module” is harmless only because it failed in the attempt to make remote attestation feasible. We must not presume that all future attempts will fail too.

[[799]]

Gesendet von ProtonMail mobile



-------- Original-Nachricht --------

--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAL8H3o9mGQP2Oqnjt4sL0_obqOMdmo1ch%2BOWT%2B_p7RSqicstBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Tai...@gmx.com]

On 11/23/2017 07:55 AM, Leo Gaspard wrote:

> Can you please avoid ranting against secure boot once again?
>
> Secure boot is *not* useless. It *does* bring security benefits,
> although not as good as measured boot with a TPM: it requires an
> additional flaw somewhere in the {BIOS, bootloader} to bypass, instead
> of just coming in and replacing a non-encrypted element of the bootchain
> by taking the hard disk out of its case without ever being noticed. So
> if you have no TPM, using secure boot is a definitive security enhancement.

The "linux" SB (ie: red hat signed grub) is only for signed grub it
doesn't sign the kernel or the initramfs, one can also mess with the
BIOS or ME which is well within the skill level of a state attacker such
as the MSS.
There are also a variety of SB exploits/bypasses.

Irregardless it'll be what eventually kills linux on the desktop for the
average person after the vendors stop including the linux signing key
(SB 2.0 specs don't obligate them to allow for owner control or even the
inclusion of the second key unlike SB 1.0 specs), if you desire such
features it would be much better to simply use a bios-embedded GRUB2 via
coreboot which supports kernel/initramfs signing features.

"Secure" Boot is a MS trojan horse.

[Leo Gaspard]

On 12/02/2017 03:11 AM, Tai...@gmx.com wrote:
> On 11/23/2017 07:55 AM, Leo Gaspard wrote:
>
>> Can you please avoid ranting against secure boot once again?
>>
>> Secure boot is *not* useless. It *does* bring security benefits,
>> although not as good as measured boot with a TPM: it requires an
>> additional flaw somewhere in the {BIOS, bootloader} to bypass, instead
>> of just coming in and replacing a non-encrypted element of the bootchain
>> by taking the hard disk out of its case without ever being noticed. So
>> if you have no TPM, using secure boot is a definitive security
>> enhancement.
> The "linux" SB (ie: red hat signed grub) is only for signed grub it
> doesn't sign the kernel or the initramfs, one can also mess with the
> BIOS or ME which is well within the skill level of a state attacker such
> as the MSS.

Ugh. Red Hat signed grub is not at all the only secure boot available
for linux: YOU CAN REPLACE THE KEYS IN YOUR UEFI WITH YOUR OWN. (sorry
for yelling but I think I've written it one too many times, maybe this
way it'll better stand out)

Please check [1] if you want to know how to do it by yourself.

As for signing the kernel or the initramfs, grub can also check the
signature of the kernel and initramfs, see [2] also (which does exactly
the same thing as secure boot except here grub is directly included in
the BIOS, so there is no need for signing it)

> There are also a variety of SB exploits/bypasses.

Of course there always will be flaws on systems, but does it mean you
shouldn't try to harden everything possible? Flaws can most often be
fixed, non-existent feature cannot

> Irregardless it'll be what eventually kills linux on the desktop for the
> average person after the vendors stop including the linux signing key
> (SB 2.0 specs don't obligate them to allow for owner control or even the
> inclusion of the second key unlike SB 1.0 specs), if you desire such
> features it would be much better to simply use a bios-embedded GRUB2 via
> coreboot which supports kernel/initramfs signing features.

Now you are just designing a future you don't like and state “that's
what will happen”. Sorry if I'm no seer, but for the desktop I haven't
owned yet a computer that doesn't allow one to change the keys, and thus
see no reason to believe what you are saying.

Also, libre/coreboot is a nice way to have a level of security
equivalent to secureboot (maybe slightly better because there is one
less step in the boot chain, thus one less possibility of flaw). But
then coreboot is not available/working on all hardware platforms, while
SB is, and the two bring equivalent security.

> "Secure" Boot is a MS trojan horse.

There is no argument to support this assertion. Please once again stop
spreading FUD.


[1]
https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot

[2] https://libreboot.org/docs/gnulinux/grub_hardening.html