Booting USB Quebes across multiple machines?

[Eric Duncan]

Hello:

Does Quebes perform a machine-specific installation? IOWs, can I install Quebes on a single USB device and share it across different machine setups?

E.g. if I install Qubes on an 8 core desktop, w/64GB ram, SSD (just keep it simple - only 1 SSD), Nvidia GPUs, etc - can I then take that exact same install and boot it in my Core i7 dual-core tablet with only 8 gb of ram without any issues?

I ask because of two reasons:

* I cannot format entire HDDs to dedicate to Qubes OS. I still do some Windows 10, iOS and Linux development and need macOS for other various things. A dual-boot setup is not "secure."

* I was thinking of setting up an mSATA drive and USB3 adapter for Quebes, encrypt the partitions and evil-maid protection and etc, and boot it in multiple devices.

I currently have it installed as a dual-boot on my Lenovo Helix (full support for 4.x btw!). But, I'd like to boot Quebes on my desktop and other machines I use...

...while keeping it secure, by using the entire mSATA drive for Quebes.

Thanks in advance!
-E

Ps, I have already attempted to try this with a USB3 stick and had possibly unrelated failures. Hence, why I am asking about the installation process and hardware configurations- if any.

Before I invest into an external drive setup, I'd like to know if there are any foreseen issues first.

[cooloutac]

I'm not sure it would really be keeping it secure that way either. dual boot is not only unsafe cause it can change /boot but also because other os could infect hardware. In other words windows or mac could infect the firmware or netcard, gpu, cdrom, etc... which could then sniff or infect your usb installation.

[Eric Duncan]

Thank you. But, my question was more about how Qubes gets installed and does it use any system properties to customize the install?

I know what you are saying though. If running Windows/macOS, a piece of firmware of a device (or bios) could be infected. And when booting Qubes from the external device, it could infect it.

Then again, that argument could be made against 100% of all PCs, laptops, motherboards of custom builds, etc - even brand new devices. So are you ever safe? Perhaps if you built your own device from scratch and coded your own BIOS.

The edge case you mention would most likely be valid only from a targeted attack, not part of a toolkit.

Say if a state actor wanted access to my Qubes install, they would need to know some very specific information:

* specific macbook with specific hardware (very likely, AppleCare registered and all, blogging/bragging of hardware used, etc).
* the exact mSATA drive and USB device I use for Qubes OS (very likely, I can just blog about it - or they can get NewEgg purchase history).
* knowledge of exact firmware versions installed on those devices.

Virtually, they would need to exploit some Windows/macOS 0-day to gain access to the machine (somewhat likely, sure). Physically, they would need to evil-maid my machines when we are gone on vacation or something (plausible, sure).

The attack would have to look like this:

1) They could devise a custom mSATA firmware to install onto the device. Well, that would require me having the Qubes OS usb device attached when booting under some other OS installed on that machine. So, always disconnect it before booting native OS. Easy.

2) They could use the exploit to infect the BIOS, or Nvidia GPU firmware - something that would boot when booting the Qubes install.

2A) that could install a keylogger, to gain access to the /boot LUKS partition password (like an evil-maid attack). plausible, yes - at a very edge case.

2B) that could install some other firmware installer, that waits for the linux kernel to boot and then side-loads itself into the boot process, or exploit some Qubes 0-day to gain root on the device. very unlikely, but plausible, yes.

So plausible? Sure, with explicit details in hand.

But that is acceptable to me as the level of sophistication required to pull off that level of attack, with knowledge of devices and their exact firmware versions, most likely would only come from state actors. (*cough* Stuxnet *cough*)

If you are worried about state actors, then yes format your machines and install only Qubes.

-E

[Eric Duncan]

To clarify my original post/question:

What does Qubes use from the physical machine's properties to set up an installation? I could not find any documentation on the site about this in the Wiki (I'm happy to contribute it to the Qubes wiki, if it can be explained here).

Some ideas I have that might cause issues with a single installation used across multiple configurations.

- # of cores are used to pre-set all VMs to # of vCPUs (e.g. like Docker does)
- amount of Memory used to pre-set all VMs to certain percentages (with a min). use swap for the rest.

But, I don't know if Qubes does this or not. Could be plausible though, if it did read these values.

I have one installation that uses the USB VM, and I think that is perfect. I can write custom scripts with that VM to look for and mount certain things depending on if they present or not (Logitech webcam on desktop, not on macbook pro, etc).

As for the # of cores/memory, I could write a script in dom0 that would "adjust" the VMs according to the system properties, before they start. That doesn't seem like a big deal either.

What I'd like to know if there is anything else specific, like graphics drivers or device drivers that are detected, installed and enabled as per the installation. Like, is there a specific Xen installation done on Qubes install?

Thanks!
Eric

[cooloutac]

well yes, but then you couldn't blame the other os, which does not protect/isolate the hardware as well as Qubes.

and ya, look at the latest intel news, just confirms what some already assume.

[cooloutac]

I would think this would be the same as on a baremetal linux, no? Probably has more to do with kernel.

[Vít Šesták]

I've asked some slightly similar question like a month ago. I was told I should run dracut without hostonly mode in order to have all the modules I need.

Your case is a bit harder. You would need to either run dracut after any kernel update (without this, it might make Qubes unbootable on other machines than the one you have updated it from) or reconfigure dracut (like edit something in /etc) if possible.

Regards,
Vít Šesták 'v6ak'

[Dave C]

To always run dracut without hostonly, make a file /etc/dracut.conf.d/no-hostonly.conf, and in there put:

hostonly="no"


I do the above to have a portable Qubes that I can boot on multiple machines. Mostly this works fine, but occasional issues:

* If you ever assign PCI devices, those will of course change from machine to machine.
* I find USB sticks get hot, and slow. I recommend installing on a portable SSD instead (which can plug into USB port).
* I have a laptop which boots incredibly slowly. There is a roughly 2 minute delay in the boot process. I suspect it is waiting for PS/2, but the machine has none. Although I'm not sure, and not sure how to troubleshoot.

-Dave

[Vít Šesták]

Most laptops do have their keyboards, touchpads and trackpoints (if present) connected via PS/2. But I am still unsure if it is your case. You might try using bootchart to see what takes long waiting at boot.

Regards,
Vít Šesták 'v6ak'

[Reg Tiangha]

On 05/29/2017 06:59 AM, Dave C wrote:
> * I have a laptop which boots incredibly slowly. There is a roughly 2 minute delay in the boot process. I suspect it is waiting for PS/2, but the machine has none. Although I'm not sure, and not sure how to troubleshoot.

If you weren't aware, you can press F2 during boot up to see the text
version of the boot sequence; maybe that might give you some hints as
well. I have an old-style hard drive rather than an SSD in my laptop,
and as it gets more and more fragmented over time with trimming VMs and
what not, the boot sequence has slowed down. Most of the time goes to
booting up sys-net, sys-usb and sys-firewall before getting to the log
in screen. That's about 2-3 minutes on its own.

[Eric Duncan]

Thanks Vit and Dave C!

@Dave:

Yep, USB sticks get too hot - and the USB2 sticks I tried were far too slow for my taste.

I have a couple of these laying around from previous laptop builds:

https://www.amazon.com/Transcend-128GB-MSA370-mSATA-TS128GMSA370/dp/B00K64HXAA/?tag=eduncan911-20

Was going to use one and the smallest msata usb3 adapter I could find, like this:

https://www.newegg.com/Product/Product.aspx?Item=9SIA6V83ZJ7496

But didn't want to buy that, and go through the trouble of setting things up and migrating over if it was going to have problems.

Hearing that you have a multi-machine setup, with just a tweak it seems, assures me.

Ordering today!

Thank you guys!
Eric

[Dave C]

I'm using an SSD similar to this, which is easily portable:
https://www.google.com/url?q=https%3A%2F%2Fwww.newegg.com%2FProduct%2FProduct.aspx%3FItem%3D9SIA6V83ZJ7496&sa=D&sntz=1&usg=AFQjCNEhmEmGAIBVz5A7wE34AkTjUr60zw

(I don't see the brand I have featured on Amazon anymore.)

One nuisance is when moving that from one machine to another, I typically have to make a netvm per computer I boot, because they use different hardware. After moving the drive to a new machine, I have to stop the firewall and netvm, switch which netvm the firewall users, then start an appvm.

-Dave

[blacklight]

well as far as i know, it will work if it meets the minimum requirements.
i wonder if your tablet supports vt-x and vt-d though.

[Eric Duncan]

I believe my tablet does support vt-x and vt-d:

Qubes release 3.2 (R3.2)

Brand: LENOVO
Model: 36984SU
BIOS: GFET56WW (1.35 )

Xen: 4.6.5
Kernel: 4.4.67-12

RAM: 7884 Mb

CPU:
Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
Chipset:
Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09)
VGA:
Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])

Net:
Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 96)

SCSI:
SAMSUNG MZMTD256 Rev: 4L3Q

HVM: Active
I/O MMU: Active
HAP/SLAT: Yes
TPM: Device present
Remapping: yes

Qubes HCL Files are copied to: 'dom0'
Qubes-HCL-LENOVO-36984SU-20170531-142016.yml - HCL Info