The point is when you see a door open, and you do not see a good reason to keep it open, lock it. If you do not use that door frequently, lock it. Qubes is like a mini corporate netowork, we have all the internal air gapped things like vault and archive vm for confidential data, and all the vms that face the public internet, and disposable vm for potential dangerous content analysis like a sandbox. What will a company do for all the machines under its network? Will they say okay we already have ABC security measures implemented, we already have XEN for infrastructure isolation/IDS for intrusion detection/Regular wipe and reset of potentially dangerous machines, so there is no need to further enhance single machine security? No, they patch / lockdown everything like there is no tomorrow. A good company that value the corporate network security have a paranoid check list, like secure boot lockdown, bios lockdown,kernel runtime integrity and control flow check, give only necessary minimal permission, remove unused authorization, cut all the unnecessary software, regular vulnerability self scan, etc… Because somehow someday something might screw you up in an unexpected way.
A penetration of a company network very likely will not succeed in one shoot, you will likely end up in possible situations like 1.Your successfully screwed an old windows computer with eternal blue but rootkit/trojan is deleted by windows defender or other antivirus 2.You payload landed in the IDS analysis sandbox and nothing real happened 3.You have spent a lot up time sending phishing emails, and finally successfully invoked a chrome browser bug in one your their employee computer, but your payload is trapped inside their customized sandbox and cannot figure out how to escape 4.You have screwed up their nginx program and prepared an esix escape exploit(they cost you 0.5M usd) but found out they implemented some fancy ASLR/grsecurity/other harden method so your exploit just somehow did not work! Even an adversary controls some sort of overkill exploits like XEN exploit, the intrusion might not succeed because of other measures in place(like their web payload stopped by adblock) or they are simply uncertain about your attack surface and their payload failed to work(like a nicely prepared payload vmware payload landed in a proprietary vm software) . And leave everything unlocked will exactly increase the attacker’s ability to gather info and finally figure out a way to screw up the victim. Doing layers of harden will decrease the possibility of an adversary performing a successful hack even they really know how to hack every single part of your system. Hacking is like blind shooting, even best hackers might fail sometimes because of unexpected things.
Also I am not asking too much, I just say we should at least follow what the mainstream linux desktop have already done to improve security. Like debian official version already use wayland by default, apparmor works out of the box, secure boot works out of the box, and has a somehow properly implemented user/root isolation. These things already have very mature solution, and not too difficult to implement them in qubes VM. In the future we can do something like graphene OS to further increases the VM security, but right now we should just followed what everybody is doing.
You can always qvm-run xterm - u root, and you can set up an shortcut on desktop specially for that
This is not a good reason to stick with it, maybe it is hard to switch because of some qubes render/graphic mechanism is only implemented in X11, but change it should be placed in schedule.
I just want a machine when you open it you can make sure it is not tampered. Developing a boot firmware for a new machine without insider document is already a highly professional work. Most likely you will need to reverse engineer the machine, figure out how things work and reimplement it, also you need to fight with the vendor who is exactly trying to stop you to do this. Best approach is just stick with the commercial solution which is making qubes compatible with uefi secure boot like debian already did that.
I think most secure boot mechanism(at least for lenovo and HP as I know) allows you to enroll your own key. Also a simpler solution is use a minized debian, verified boot into that debian and kexec into qubes like what heads did.
It depends on the cost. I think if your attacker has enough resources to get a Xen exploit, it’s highly likely they will also have a Linux exploit. You probably should find other security measures like a good firewall, instead of using Linux for protection.
That is a quite simple and great solution. I have deployed sensors with a separate chip on the back cover, it will be triggered when back cover is detached. I have designed a simple challenge response. If back cover is not removed in a designed way then the chip wipes the keys which cannot be undone by an adversary. When the challenge response fail I will be 100% sure my laptop is tampered.
Purism maybe has a good ideology, but their products still cannot compare to the reliability of those big vendors. I have seen some posts complain about their laptops with many kinds of problems. Also mainstream products are cheap and powerful because of mass production, a good OS should be compatible with these new mainstream products.
It is a quite simple project, like those beginner level Arduino project you turn on led when a switch is pressed. I sacrificed a usb port for charging the battery, I soldered the power cable directly on the usb port. Those low power Soc should be able to stay for months even laptops is power off without any problem.
interesting, thought i like to drill a hole on laptop case (or use magnetic usb-c cable + plug) for charging that battery rather sacrifice a usb port
what sensors (and soc if not some arduino or pi pico) you use?
so what if they (someone who want to tamper you laptop) find where that sensors then loosen the screw and put something thin to not trigger the sensors?
Do not be too paranoid bro
For my threat model I am not a high value target at all, and I research Qubes OS as hobby. So I do not worry someone will do some highly customized attack on me.
Actually you already made a lot of assumptions like adversary knew you are using Qubes, and they are already equipped with Xen zeroday exploit to attack so other defenses are pointless. Actually maybe 50% time of an attack is spent on determining attack surface.
Just think like an intruder. For example you are a government employee, and you have seen me sharing some sensitive document on a forum. You would like to silence me, what will you do? You will try to contact the forum ask them to put a trojan on their website, and try to hack me and leak my location. You will have no idea that I am using Qubes at all. You will first try to crack my tor browser with some zero day or send phishing email to get a small trojan inside my OS. At this stage you only know I am using Linux, so you will send a very generic small trojan to my OS first. That small trojan will phone home to download the big trojan for further surveillance if it runs successfully. Then you will start to manually sending commands to the big trojan to find something interesting, and you review all the info the big trojan sent back. After all these things you finally determined I am using Qubes + whonix, then you opened the exploit arsenal hope to find some whonix/Xen exploit to screw me. All these things take time because Qubes OS is not like iPhone that have a quite certain attack surface and large user base so an exploit solution is already in place. At last you found the correct exploit and my dispvm is still online. You push those exploits to the trojan for execution and i am screwed. Restrictive security policy and sandbox will definitely slowdown even completely stop you at the initial stage, also all the security measures increase the difficult for you to collect intel. This chain of attack requires a lot of money and luck to really work, and I definitely think put more barriers will increase the difficulty and uncertainty. A well designed in-VM security architecture will definitely help those people who are really at risk.
