I will get straight to the problem. It is a big problem to not have boot security. A modern laptop that isn’t qubes-certified usually has boot guard in verified boot mode which means coreboot isn’t supported which means Heads isn’t supported. Same laptop will have TPM 2, not TPM 1.2 so AEM is not supported. This leaves only UEFI secure boot but this is not supported in qubes os. This means a modern laptop that’s not qubes-certified will not have boot security.
However, UEFI secure boot is supported with Linux.
When most people compare linux against qubes os it is compared that the linux os will not use virtualization but this is unfair because you can with some work, configure a linux system with qemu/kvm to be very similar to qubes os. You can create all the sys-usb sys-firewall qubes/VMs there as well. And you can have disposables as well but it takes a bit more work usually. But at least with kicksecure you can choose to start the VM in normal or live mode every time so if you need to do maintenance you start in normal mode, then switch to live mode which is similar to disposable mode. You can also use snapshots. And it would also be more inconvenient opening files in a disposable but it can be done just takes more work and effort. Overall the user experience is of course a lot worse in Linux and it takes also a lot of work to make it comparatively secure as qubes OS. You can’t just install Linux and everything is ready to go, there is a lot of work to do first.
The question comes down to, is the extra OS security and more user friendly experience in qubes os worth it when qubes os on a modern laptop which is qubes-certified doesn’t have boot integrity.
Maybe you are tempted to say “just buy a qubes-certified laptop” but that would be a different topic regarding root of trust and effectiveness or ineffectiveness of anti-interdiction tamper evident packaging.
It could be worth it to stick to Linux if you don’t mind doing work to configure it to be as similar to Qubes OS as possible, until Trenchboot has support for TPM 2, then you can have boot security on qubes os with modern laptop that isn’t qubes-certified. I’m not saying Linux is more secure until then, I’m just opening a topic for discussion about it.
I don’t think secure boot is really useful. Linux initramfs could be tampered with, secure boot only checks the kernel, not the immediate payload that can’t even be encrypted.
my limited knowledge =
Qubes is a personal computing oriented Xen implementation which separates most of the outwardly facing components of the computer and software from the users applications. Qubes OS is linux so comparing qubes os with linux is comparing linux with linux. You can compare the QEMU/KVM virtualization platform with the Xen Virtualization platform. (IMO Xen is better) I have tried to use QEMU/KVM in the way you are talking about but replicating Qubes without vast technical knowledge and experience is not feasible or a worthy use of time. Secureboot on a qubes system seems kind of worthless because to tamper with the boot region someone would have to have infected dom0 which is already gameover and extremely unlikely.
Not just that: Even most Xen vulnerabilities do not affect Qubes OS, and those that do almost never lead to an escape. The last true escape was discovered in 2006 by the Qubes founder.
I think it is subjective whether or not having an extensive virtualization architecture is enough to distinguish oneself from being whatever the kernel is on dom0. I guess one could make the argument that it is a Xen/GNU/Linux distribution and not a GNU/linux distribution since the software which was produced by the project is Xen oriented but at the end of the day most still say linux when they talk about GNU/Linux be that a failure or not.
Commercial “Secure” Linux systems use a stripped down Linux and a customized version of Virtualbox.
You can buy a “certified” lenovo laptop and a proprietary distribution. Here they focus on a god user experience of the common winodows user.
Linux and Virtualbox are built around the guest to allow for VPN and especially for ipsec style $custom_government_closed_source_super_secure_cypher to be used in a sepcialized Linux (some stripped down distro like ubuntu or suse)
If you buy one disect it and tell us more. I have only rumors and assumptions.
It is true, one could use any virtualization, and also container environment to have a secure desktop.
You could run proxmox VE and a thin client linux as “super guest” which is started at boot time to run VNC-term to connect to the proxmox machines.
Proxmox is not so bad and has also features like hot switch over, so one could have a server and a laptop and if one wants to go he could theoretically take a running session from the server on the laptop and continue work there.
So there could be a proxmox VE based qubes also.
As proxmox runs LXC and KVM it is interesting for operating fake android phones using a hypervisor that needs vt-d like https://www.genymotion.com/
So the genymotion could also run in an LXC container sharing the kernel of the proxmox machine confined in namespaces, cgroups2 and se linux.
Just some unorthodox thoughts,
there are other hypervisors besides xen. E.G. KVM
“Thou shalt have no other hypervisors before me” shouts XEN.
Proxmox VE can be installed as a guest on all common used desktop virtualization solutions as long as they support nested virtualization.
“Thou shalt have no other hypervisors before me” shouts XEN.
To quote Darkstar: “May be there is a way”. “benson arizona …”
Update:
I tested it in graphic install mode as stand alone VM as one would install windows 8.1 (works, is not worth a mention) and got a popup reading:
“No support for hardware accelerated KVM detected”
“Check BIOS settings for Intel VT / AMD-V / SVM”
So you can say thank you Mr. XEN.
But XEN says it is able to do nested…
BTW: top left in the screenshot> a browser short-cut for sys-net is nice for using wifi captive portals.
How to use the internal Qubes-OS net?
Is there comprehensive documentation about it. Do we have softswitch or some other tool to manage the internal net?
A virtual VLAN-switch with ports to assign to different VM-guests would be nice. In the style of the qubes-manager. A DHCP server to be assignable to VLANs and Ports and with some configurablility would also be nice.
I can not use the proxmox web interface and tried 10.x and 192.x net.
Also I checked “provides network to others” in the qubes-manager.
The kernel and initramfs (some kind of very minimal linux to boot into your real system) are not encrypted, they exist on the boot partition which can’t be encrypted.
At some point, an installed software must exist unencrypted to unlock encrypted data using the passphrase / hardware token. This is where the risk exist because you can’t protect it. The best we can achieve is to check if the file was modified (using Heads or Secureboot), but secureboot only verify a small part of the boot process which is almost useless.
So how real is this danger to compromise an encrypted system? I dont really care for tampering with the boot process, if my encrypted stuff stays encrypted as long as they dont have the password what could go wrong?
The risk is “evil maid attack” which consists of tampering your boot process to inject a malware into your system. This requires a physical access to the computer (or access to /boot partition but it is very unlikely on Qubes OS remotely).
you could get an Install of duely signed friendly agency ME payload from usb or network at the airport.
It reads your disk mantra from kbd and sends it via icmp to $your friendly agency. What can you do against ring -3 and saurons eye?
Warning!
Dont tell anyone lest they throw you into an asylum for having mental disorders. Another snowden then needs to prove you right for release
Hint:
Asus KGPE-D16 mainboard with 2nd gen of matching opteron cpu can be hacked into a trustworthy workstation.
This evil maid attack which req phys access, does it require they open the computer up with removing screws? Or is it enough to connect a usb flash drive and then start the computer?
I don’t know enough about what kind of attacks are possible but I thought qubesos with default configuration makes sure that usb only goes to sys-usb. Also set password to access BIOS to prevent booting from USB. Then the attacker would have to remove screws for a more advanced attack?
I also know there are more attacks like replay and relay attacks but that is something Heads can’t protect against as, i guess aem can’t too.
Everything in kernel & initramfs is public anyway, so encryption seems not to be necessary. If we can ensure only our known kernels and data are loaded, then it needs work inside the computer to trick us with a fake boot environment.
Not quite. There are other anti-tamper measures present that can be useful in situations like this.
Well…You can configure a Linux distro with QEMU and KVM to appear to act like Qubes OS, but it will not be a one-to-one.
And…knowing full well, no doubt, that the host OS can see into every single one of your VMs without exception, do you trust what you’re running all of those VMs on top of? Keeping it clean and sterile? No network access?
Is a Ferrari with bald tyres worth it? It’s better than no Ferrari.
I am incredibly tempted to say this, because it’s a no-brainer. Those with the budget would likely not try and hack whatever they had lying around into a workable solution, if enough was at stake for them.
Not the solution for everyone, but if I was going into outer space, I would prefer to be in a purpose-built spacecraft than a Skoda Fabia that I put extra rubber seals on…
Yes and no. It would be a case of you reading up on what they have claimed they have done to their hardware they have sold you, and you verifying those claims, or seeking out someone you trust to verify them for you. And if the claims turn out to be unfounded, then you have to make a choice on whether you wish to use the device or not.
Those vendors are able to have success with their qubes-certified products because they allow anyone to audit their claims who wants to, and there is very little hindrance to doing so, besides a little technical know-how.
Not necessaily. Linux and Xen do not share codebases, and have very few similarities, and do completely different things.
You should use whatever meets your needs, and you feel most comfortable using.
Incorrect. It does have support for TPM2. That was the whole point of the project.
Incorrect. Qubes OS is Xen with other kernels/OSes running on top of it.
That isn’t an apples-to-apples comparison, really. They are too far-removed from each other. QEMU is userspace software that is reliant on the KVM module of the Linux kernel, allowing the kernel to take care of virtualisation. But if you run multiple VMs, they will all share the one kernel, and the amd64 speculative instruction set can be manipulated to read data from other VMs, not to mention the quintessential “use after free” exploits which doesn’t result in system leakages on Xen.
Not true. Simply put, in order for a computer to be able to boot, the binaries it needs to be accessible, which means they need to be either:
Unencrypted on a block device (hard drive)
And accessible with full write privileges if mounted as just a regular drive, for an attacker, I might add…
This is essentially the old-fashioned way to un-bork your Linux/BSD machines back in the day… OR
Encrypted in a way that the computer can make sense of them
This is what a TPM does. It stores the encryption keys, and when you power on your computer, if all its checks pass, then it loads the encryption key into RAM, so that the CPU can understand what’s stored on the drives.
The kernel in dom0 on Qubes OS currently is Linux. Dom0 is a virtual machine sitting on top of Xen.
It’s a good thread, I’ll give you that, but “I’d just like to interject for a moment…”, and say how is this related…?
Again, no thought as to the inegrity of what VirtualBox is running on top of? The thing that can see INTO all your VMs? Just saying, that’s a pretty big flaw…
Can’t verify their claims independently. Have to let them manage everything for you, and pay them for the privilege.
Kind of like those “third party code audits” companies of proprietary software come out with.
They’re good because that guy says so
“Er-hem…in short, we were paid a large sum of money to sign an NDA, and then tell everyone we quote-unquote ‘looked’ at their codebase, and couldn’t find anything malicious. Uh, they also said they wouldn’t pay us if we said we found anything, either. Oops, I wasn’t supposed to say that…”
Suppose there’s probably someone out there who finds products like that appealing, but it definitely ain’t me…
This is nowhere near even remotely comparable to what Qubes OS does… Qubes OS does so much more, in so many better ways than that.
Have a read of the GUI virtualization developer docs. You’ll be pleasantly surprised.
Nested virtualisation = Direct hardware access, which you’re not going to get on Qubes OS, and that’s by design. Hardware access = increased attack surface = VM escape.
It would be a massive attack surface if there was…
Check the dev docs.
Your actions are strikingly similar to a piece of malware when let loose inside of a qube. Qubes OS has been specifically written to deny all of what you’re doing, and make it as difficult as possible.
Have a read of the qrexec protocol docs. It’ll give you what you’re looking for.
That’s because there’s no DHCP server, and this is by design.
Read up on the qrexec protocol and dom0 policies. You’ll find the answers you seek there.
An idiot with an open mind is not an idiot at all. Quite the opposite actually
@SNACK, have a think about how exactly your computer knows how to decrypt your files…
When you turn your computer on, once you give it the correct key (password, certificate, or anything that allows it to make sense of the seemingly garbled gibberish that’s stored on your hard drive), it stores the key in RAM for the entire time the computer is powered on (including when it’s asleep).
If it didn’t hang onto it and store it in RAM, you’d pretty much have to reenter it every time you wanted to read/write a file
The following are not tinfoil hat conspiracy theories, and have actually occurred in the wild:
Malicious RAM chips that figured out where the key was stored, and “froze” the cells that the key was stored in, so that an agent could retrieve them from the laptop for dumping the keys later
Replacing kernels in the boot partition with custom-written ones that “do extra things” (usually nasty things)
The infamous CrowdStrike incident is the perfect example of a bad thing that can happen when boot integrity is not deemed important
It’s not necessarily about preventing tampering, but being able to at least detect it, so that you, the end user, can make an informed decision about what do to next.
Very real.
You really should care…
Let’s say you just loaded my malicious kernel that logs your keystrokes and sends them to me. I watched you type in your password in real time. I also have complete control over your entire computer, because the kernel listens to me, and not you…at least until you reboot
Anything is possible under the right conditions, but the best thing you can do is familiarise yourself with the ways it could be done, so that you know what “dumb things” not to do that could potentially let in unwanted guests.
The Evil Maid Attack is, by definition, someone physically interacting with your computer, and you are unaware of the fact that they are doing so. You, the owner of the machine, do not necessarily need to be present, but the trick is, you aren’t aware that it’s happening.
These all fit the defiinition of evil maid attacks:
A fellow student sitting next to you in a lecture theatre deliberately pulling out your power cable, causing your hard drive to corrupt
A colleague in a business meeting secretly plugging in their Walkman into your microphone port and blaring 2Pac while you’re in the middle of a video call, so nobody in the call can hear you speak
Asking a friend to view their photo album on their phone, and then once you’re holding their phone, secretly adding “questionable” photos into their album (a few selfies, various parts of anatomy, etc.) while pretending to swipe and view other photos
And yes…a housekeeping maid coming into your hotel room when you are somewhere else and jamming in a USB stick into your laptop to load malware onto it
Flashing chips (essentially interacting with them as if they’re disk drives and just copying stuff onto them, overwriting whatever was previously there before) is often a lot easier than having to “trick the already running software into letting you in”, but it’s not the only way.
It’s also much MUCH easier to edit a filesystem when it’s not the boot drive, and you’re not fighting existing running processes trying to deny you access.
Again, it depends on what both the USB stick and the computer do when they meet, and how they interact (protocol), and whether one party tries to manipulate that protocol, and make the other party do something it’s not supposed to do.
Sys-usb does start very early in the boot process, and dom0 is told to ignore USB controllers until it has completed the boot process, yes, but there are times when the USB ports are active, such as the LUKS password screen in the initramfs.
Mitigations are in place in the initramfs, though, but nothing is ever 100% bulletproof, unfortunately. Eventually, someone may find a way to exploit this, and thus continues the endless cat-and-mouse of find vulnerability, patch vulnerability…
Ah, the Circle of Life.
Most likely yes, followed by a quick reflash of your BIOS chip to factory settings.
There isn’t really anything in the boot process to “replay” or “relay”, anyway. There also isn’t really anything operating at that time that can “receive” anything that could be relayed, either… The NIC on some newer machines, maybe, but not much else…
So no, Heads will not protect you against someone stealing your browser cookies or kerberos tickets, but then agian, it’s not designed to do that.
Heads is designed to ensure that, to the fullest extent possible, you have a snapshot of your entire machine as it was when you last shut it down and went away from it (and you carry it around with you), so that when you come back to it and turn it back on, you can take another snapshot and compare the two to see if anything hardware- or boot-related has changed.
Microsoft seems to think it’s worth encrypting. That’s what Bitlocker does. Locks up your kernel at rest, and stores the keys inside the TPM.
However, there’s nothing forcing you to keep your boot partition and root filesystem on the same drive, or even inside the same machine.
It’s not unheard of to have an SD card, external flash drive, or PXE server as the boot partition, instructing the machine to boot off the internal hard drive. It’s also possible to detach the header of the LUKS partition (the header stores things like where files start and finish on the drive, partition maps, etc.) and store that separately to the encrypted data.
Not for everyone, but hey, it’s an option.
You have pretty much just described boot integrity
Signed by whom? Linus Torvalds? Microsoft? Are you self-signing your own kernels?
What if I enrol my own malicious kernels and signatures into your BIOS?
Again, it’s the same root of trust issue that plagues us.
Whilst prevention is more difficult (and likely, given the nature of the amd64 boot process, almost impossible), there are still ways to detect most forms of tampering on most machines. There is no one-size-fits-all approach, though…
Very informative post, thank you. I am convinced now that Qubes OS is more secure even without boot integrity than another linux os with secure boot.
Unless Trenchboot very recently began supporting TPM 2 I think you are mistaken. It’s true the whole point is to support TPM 2 and replace AEM but every single source I’ve read is that it something they are planning and working towards but haven’t yet achieved.
For example they say they use some kind of microscroping x-ray to look for microscropic chips hidden inside the silicon but they also say this is very difficult and there’s a good chance they won’t find such a chip if there is one hidden in the silicon. I can’t remember where I read this so I apologize for not having a link to source.
The tamper evident tape is not good enough against state actors and glitter nail polish on screws if done correct and optimally would require a lot of time to remove and re-apply without evidence but feds who have their facilities the intercept packages will have plenty of time, no stress and have trained experts with experience to do this.
And we just don’t know if the owners of the qubes-certified stores are secret state actors themselves. Mossad have publicly said on a 60 minutes interview that this is the type of stuff they do a lot. Setting up shell companies for shell companies and blend in and do lots of tampering for mass surveillance. They didn’t mention Qubes OS specifically.
That’s why it all comes down to two things: is tamper evident packaging good enough? probably not. Can we trust the store owners to not be secret state actors? That’s up to you who you want to place trust in. We have to place trust in some company but which one is up to each individual.
