Security Consequences of Dual Boot with Different Drives

General Discussion
#1

I have a laptop with an M2 SSD and a 2.5 inch drive. I can start one or the other from a change in BIOS/EFI.

If I install Qubes on the M2, and Windows on the 2.5 inch drive. What is the additional risk of this implementation?

I would guess that whatever you do, if you look suspicious to Border Guards, or Police. then the next level of searchers will know where to look more deeply.

Like being a Journalist? Or Guard asking, How do you explain all the countries you have been through recently?

(off-topic)

I have been looking for a more complete Opsec for being a Journalist. (just that is the group who has been working on this issue for a long time.) Also settings changes made in Qubes? Does anyone know of a website that works on specifically Opsec for Journalists? As this discussion is not part of Qubes.

There is the standby, carrying a clone of your OS in a Micro-SD inside a Rubik’s Cube.

Or setting yourself up to quickly create a Tails USB, with your own prearranged Bridge. and so on. Just to send out copy.

Really, how dangerous to my computer security to have a Dual Boot with different drives?
Is there one Web Page were Journalists discuss using Opsec of using Qubes?

1 Like
Qubes Opsec for Journalists
Feature Request: Peace of mind when crossing borders
#2

If Windows has the access to the Qubes drive, it can compromise the unencrypted /boot and with it the whole Qubes installation. You can probably detect it with Anti-Evil-Maid or hardware key (like Librem Key) but you can’t prevent it AFAIK.

See also: Verified boot on Qubes -- a lofty dream? and Is it possible to enable UEFI Secure Boot in Qubes OS?.

Perhaps this might helpful: Surveillance Self-Defense | Tips, Tools and How-tos for Safer Online Communications. It’s not specifically about Qubes, but Qubes is mentioned sometimes. Also, Qubes is just a meta-OS which isolates your inside-operating-systems. Everything in the link applies to them. In addition, consider compartmentalizing your workflows.

I moved your post to a new topic to make it easier for new users to find the answers

#3

Windows is a total open hole. Backdoors built right into it by default.
When you boot to Windows on the machine, you’re subject to a bios level attack, that would carry over to your alternate boot.

I would only use Windows sandboxed inside a Qube.

(What you do is important…stay out of jail… keep your colleagues out of jail. Get your journalist buddies together, and lets fund a proper PD layer implementation in Qubes 4.2.)

2 Likes
#4

My laptop has dual boot windows and qubes with encrypted boot and detached header.

I don’t believe it would bypassing encrypted boot with any wireless attack (you mention it), if bios firmware haven’t been tempered in the first time we bought the device.

I really know what threats are present when using modern devices, I will use offline devices if I need security, zero trust is absolute.

#5

Can this issue be solved using the coreboot grub2 payload?

The payload supports booting from LUKS encrypted partitions, and you can lock the BIOS section of coreboot. Wouldn’t that give you a system where you can’t access /boot or the bootloader, unless you know the LUKS password and have physical access to the device?

#6

I guess one way to mitigate that would be to use it on an external ssd. But that would raise suspicions on border crossings.

Border Crossings With Qubes Without Raising Suspicions
#7

A post was split to a new topic: Border Crossings With Qubes Without Raising Suspicions

#8

@catacombs I think there are many questions in your post. For the sake of organization it’s easier if you stick to one question per topic. It also makes it easier to find the discussion and to keep it focused.

I’ll be creating separate threads for the other things. I hope you don’t mind.

For example: Border Crossings With Qubes Without Raising Suspicions is more suitable as you start by the problem and not by a specific solution (2 SSDs)

1 Like
#9

A post was split to a new topic: Resources for Opsec For Journalists

(restricted to trust-level-2 members as it’s not qubes-related)

#10

A post was split to a new topic: Qubes Opsec for Journalists

#11

From the Qubes FAQ:

#12

  1. Installing Windows and never use it. And delete the WiFi driver. Add some average looking thing, texts, so Windows does not look never used.

  2. UEFI; I notice Ubuntu has bought a license to use. I am actually unclear whether the posts about Qubes 4.1 and UEFI is about getting around UEFI, or some computers can use UEFI with Qubes 4.1, and some can’t.

  3. Is there up to date advice about installing computer Firmware related to Windows 11 and of course Qubes 4.1. That is; I read that one of the things patched is the TPM, because - I guess M$ and Intel agreed that the complexity of creating PGP keys was not good enough in the earlier TPM. I don’t have Core Boot or Heads, or know what how they allow/handle the issue. I am going to have to figure out how to use Nitro Key to create PGP Keys. Assuming they do not use the TPM.

#13

From what I understand, you mean adding data to the Windows partition without running/booting Windows.
This would not be enough. Suspicion will arise if for example the system is not up-to-date, and the system logs (event log) will show that you’re not effectively running it. Also the access times of a lot of files will be in the past.

For the other two questions I can’t help.

Another suggestion would be to use OPAL drives, but I’ve yet to test it. Better ping @slcoleman, he’s the one who mentionned it in the original topic.
I’m thinking installing Windows in the normal partition and Qubes in the hidden one.
But this would not prevent Windows malware to alter firmwares, but then you could check them and restore them from Qubes ?

2 Likes