Tails

#1 Updated by intrigeri 2015-07-12 03:31:46

I’ve just pinged boyska.

#2 Updated by intrigeri 2015-07-12 03:56:49

boyska can’t work on this before September, and even then he encourages me to find someone else to work on this. Not sure how to proceed — probably I’ll send a call for volunteers on tails-dev@ + debian-live@, and then unassign this from me.

Also note that live-boot (at least 5.x) already supports some kind of UUID checking, but it’s not suitable for security purposes: the UUID is generated at ISO build time, embedded in the initramfs and in the ISO filesystem, and at boot time the initramfs checks that the UUID on the boot drive is the one it knows about. Given the content of the ISO is public information, an attacker can very well plant the same in their fake Tails they put on the internal hard drive, so this doesn’t help wrt. “not load the OS from an internal hard drives, while still looking for all devices even though they say they’re not removable”.

#4 Updated by intrigeri 2015-07-16 06:33:57

boyska pointed out that a UI like live-media=boot-disk would be nicer than FSUUID=. However, I’m not sure if the initramfs has any reliable means to know what filesystem it was loaded from.

#7 Updated by intrigeri 2017-04-11 15:09:11

This (re?)implements bits I was mentioning in Feature #7475#note-2:

• https://sources.open-infrastructure.net/software/system-boot/commit/?id=15f1ef92c73e7c9978fa43ae260dcb17b4bb85aa
• https://sources.open-infrastructure.net/software/system-boot/commit/?id=fd810a7c5238515a33374f5beaacb2b5621f7c88
• https://sources.open-infrastructure.net/software/system-boot/commit/?id=744473a627a01a39d1209fcaf75cb3a3cf46ba86

It’s still not suitable for security reasons, but if we combine it with what I describe on Feature #6397#note-42 (that would be enough to solve the parent ticket), then we get a nice bonus UX improvement (no more random behavior anymore when starting a computer with two Tails sticks attached), without having to fiddle with anything bootloader-specific. These two solutions can be combined as live-boot looks for the UUID only on devices that satisfy whatever live-media= specifies.

#10 Updated by intrigeri 2020-03-09 19:01:42

intrigeri wrote:
> This (re?)implements bits I was mentioning in Feature #7475#note-2:
>
> […]

These URLs are broken currently but I have a clone locally. tl;dr: embed a UUID generated at build time into both the initramfs and the SquashFS; then, live-boot will look for a SquashFS that has the same UUID as the one found in the initramfs.

> It’s still not suitable for security reasons, but if we combine it with what I describe on Feature #6397#note-42 (that would be enough to solve the parent ticket), then we get a nice bonus UX improvement (no more random behavior anymore when starting a computer with two Tails sticks attached), without having to fiddle with anything bootloader-specific.

That’s true only when the two Tails sticks have a different version of Tails. If they have the same version of Tails, then the UUID will be the same on both sides, and then the SquashFS can very well be mounted from another USB stick that the user elected to boot from ⇒ confusion. IMO that’s not good enough.

Additionally, now that we have FSUUID= passed by syslinux already (and soon by GRUB), “without having to fiddle with anything bootloader-specific” is not an advantage of this approach anymore.

So I think we’re back to square one: nothing new on this very issue allows us to drop the idea that live-boot needs to honor the value passed with FSUUID= (which has drawbacks, that I’ll discuss on the parent ticket).