Hello,
I am aware that dual-booting QubesOS with other operating systems compromises the security of QubesOS because of the ability for the other operating system to interact with /boot.
If I were to install QubesOS on an external drive, would it maintain its security if I do not boot into anything else while it is attached? Are there any vulnerabilities to this approach I am missing?
Additionally, would the installation on the external drive be vulnerable if it was attached to a different machine? I don’t understand LUKS well enough to know for sure, but my intuition tells me that an encrypted drive that is vulnerable to a dual-booted operating system would still be vulnerable on someone else’s dual-booted operating system. If so, is there a way to circumvent this, perhaps using a hardware authentication device?
Hi @goto.enthusiast, welcome to the forum!
Unfortunately, this doesn’t have anything to do with LUKS. It has to do with the interactions the unlocked partition(s) have with the hardware they’re running on.
In privileges and permission of a computer, the general rule of thumb is that the earlier the program starts in the boot process, the more stuff it can do/touch, because it has fewer program under it who could deny it.
In other words, if a program is going to deny another program access, it has to have started before that program (for example, the Linux kernel denies Thunar access to a directory on a disk, because Linux started before Thunar, and is able to tell Thunar what to do).
When you boot into an OS, generally that OS has full (or close to full) control over the hardware, which can include your Qubes OS installation, if it is present.
Given the way it’s encrypted, and the fact that the algorithms are “safe enough” for now, your LUKS partition is, for all intents and purposes, safe from harm when it’s at rest, or not unlocked (except if someone wants to overwrite it 
).
When it’s unlocked and mounted not as a boot device, though, is a different story…
Just like you can usually touch any part of a Linux, Windows or macOS installation when you haven’t booted from it, this can also be done to Qubes OS.
This is actually how almost every Rescue ISO works 
Generally, the only thing stopping the user from destroying the boot device is the OS running on it. And if that OS sees your unlocked Qubes OS LUKS partition (or your boot partition on your external drive) as “just another external drive”, then it generally won’t mind if any program reads from it (SSH keys, etc.), or writes to it (plants malicious files, etc.).
And then, the next time you boot, it could potentially be Game Over™️ for you, your hardware, and your Qubes OS installation.
So, in answer to your questions:
It would be no different than if you had the drive as an internal drive.
(Of course, just remember that you’re likely missing out on some of the killer features of Qubes OS. If you’re connecting by USB, you likely won’t get USB passthrough unless you have multiple USB controllers in your machine 
)
Your Qubes OS would likely be able to touch whatever it wanted to in your internal drive partitions. As long as it didn’t execute anything from there that was “nasty”, you should be fine
An OS installation is vulnerable to the hardware it is attached to, and the drivers/firmware that are required to manipulate that hardware. So, yes, it would all depend on whether the hardware on that machine was doing anything “nasty”.
Just remember that if you migrate your installation, depending on what hardware they have, it is possible to propagate certain types of malware across machines. This is how WinLNK got spread across Windows machines a decade ago.
So yes, it is definitely possible to contaminate your Qubes OS installation if you move it from machine to machine, especially if you don’t know the make-up of (or trust) the machines you’re running it on
No, you seem to have a sound understanding of LUKS
If you know exactly what a computer’s hardware is like before you boot from it, and you know that “everything is fine” (known as a “trusted state”), then yes, it is possible.
This is how Anti-Evil-Maid works. When you shut your computer down, it takes a very detailed snapshot of your computer hardware, and you then take that snapshot with you when you leave your computer unattended. Then, when you return and turn your computer back on, it takes another snapshot and compares the two. If they are the same, then it’s safe to assume that nobody has fiddled with your computer.
If they are different, well, you can guess the rest 
But this isn’t really possible on hardware you’ve never audited from a trusted state before
This is one of the many reasons why you will hear many people discourage you from booting Qubes OS from an external drive, as well as moving it around between hardware.
It will definitely execute on other machines, but because you might not have a trusted state, you cannot be 100% sure of:
- what exactly you are executing
- how it will interact with the hardware
- what the hardware might do to your Qubes OS installation, the device it resides on, the controller it’s going through, or anything else in the chain that gets Qubes OS from your external device, into the CPU.
I hope this makes sense
I have qubes installed on a partition on my internal drive, but I told the installer to put /boot and /boot/efi onto a usb drive. Nothing else I run has access to my system unless I decrypt the luks container in that system (assuming some malware isn’t in control of my laptop’s firmware, then i’m screwed either way). You could also place the luks header on an external drive if you wanted to hide the fact that there is a luks encrypted partition there at all, there is a forum guide on how to do this. The caveat to having /boot on an external drive, as alzer89 stated, is that I need to have at least one usb controller permanently attached to dom0. This is acceptable to me (kind of) as I still have 2 usb-c ports that I can attach to a usb qube and my usb-a ports are used for booting and keyboard/mouse. I also need to set noauto in fstab for boot partitions so that I can remove my boot drive, and I need to pass my boot drive to dom0 via usb qube as a block device to mount /boot when updating dom0 (my usb qube is disposable so I just restart it before doing this).
It’s not the best setup, but it’s the best I could come up with given my hardware/requirements.