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.
@ppc very helpful links thanks!
Hadn’t considered how noticeable measures (ie glitter polish) might attract attention. Will now add little wax to unused ports too.
Any other physical tamper evident methods? (outside or inside)
