On 11/19/2016 02:31 PM, Marek Marczykowski-Górecki wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, Nov 19, 2016 at 07:20:56PM +0000, Fred wrote:
On 2016-11-19 11:54, Andrew David Wong wrote:
On 2016-11-16 13:31, Fred wrote:
A good time to ask if Qubes encrypts /boot in it's LUKS setup. I've
not
checked myself.
By default, Qubes does not encrypt /boot. Traditionally, that's
because doing so would render the
system unbootable. However, that's no longer true with newer versions
of GRUB, which are now capable
of booting from encrypted block devices. So, it's worth considering
for Qubes. Tracking:
https://github.com/QubesOS/qubes-issues/issues/2442
Yup. I know these days GRUB supports LUKS and things like mdadm, LVM etc so
the days are hopefully gone since people need to worry about the position of
/boot on disk or which esoterica are required to boot (and any intitrd
issues).
I guess the bigger question is if it actually provides any real added
protection? Someone can still re-install GRUB by booting from other media
and reinstalling GRUB. If the authenticity of /boot can also be verified
then maybe it does? But once physical access is gained the game is over I
guess?
Yes, exactly - if any of the boot chain element can be tampered with,
attacker can subvert it to intercept disk password and/or infect further
elements. It doesn't matter if that's whole /boot, or just stage1 of
GRUB in MBR.
The situation is somehow better when your firmware can handle disk
encryption (like Coreboot with Linux or Grub payload can) - in this case
the whole disk can be encrypted and attacker would need to re-flash the
firmware - which is somehow harder, take more time etc. But still
doable...
- --
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 v2
iQEcBAEBCAAGBQJYMKijAAoJENuP0xzK19cs770H/iKHTrMfdbFJSu53orcYNAVP
QLwDKzg7FVLHqcHYzwWe8Cu0pRxwHZwFzFZFyH6de96EmCa9FehJzuTFefUvOZ0T
HJ9ilXuIzpiarzxPO9UISLnhd1Qg/5xOWy6e7DS1BjWXsXjakek2/h+/wIsy8FCV
B0SFFFTo6Yiuxy0gThb1cNmLMlORCrVzt5mlENRyxz6KfmmM7mDhSaf7+hhfXAkX
28mz0jvuTqs56iJ07E9poWOCy5nDGAAposlp7GJSKmngMXQxPpdTOmXoSNMaPwii
BxnvPgyzBEoPg3FDPdUHsAOFPFy+0WeBxlpA6ykQ5qAZ9NsuWG3esYpIoPmdhRM=
=rNAe
-----END PGP SIGNATURE-----
Or considering as coreboot (and the proprietary firmwares) doesn't
initialize IOMMU (yet), a DMA attack in the pre-linux dma prot initl
window is also a viable option.
Turtles all the way down man.
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/f7e034fc-15e5-aeb8-1ba6-f9fa64fbae35%40gmx.com.
For more options, visit https://groups.google.com/d/optout.
