Welcome to the forum @zphaskqjrm, it appears you have been a member of the community for a long time.
1.Root> 2.Kernel> 3.GUI
I challenge that all three of this topics have been addressed over the years over and over. The basic question to you is: what do root privileges or a kernel/X11 exploit buy the attacker? How does any of it make a XEN exploit more likely? The attacker is already in domU and all the data there is exposed. What more can the attacker achieve now?
Not a bad idea, I suppose if you run a lot of stuff in a single qube … but why wouldn’t you just distribute it over multiple qubes instead?
6.Root of trust
Any ideas beyond AEM / heads?
I have used Qubes OS for many years and saw how it grew up from an idea, and I have seen no reason it should not further increases its security.
There is no reason, just money and time constraints. Anyone can donate and contribute!
however, don’t think i don’t want this to be true, i love it if this can become default in someway (like create a version for it, make a switch, …)
# WTF?! Have you lost your mind?!
# In Qubes VMs there is no point in isolating the root account from
# the user account. This is because all the user data is already
# accessible from the user account, so there is no direct benefit for
# the attacker if she could escalate to root (there is even no benefit
# in trying to install some persistent rootkits, as the VM's root
# filesystem modifications are lost upon each start of a VM).
# One might argue that some hypothetical attacks against the
# hypervisor or the few daemons/backends in Dom0 (so VM escape
# attacks) most likely would require root access in the VM to trigger
# the attack.
# That's true, but mere existence of such a bug in the hypervisor or
# Dom0 that could be exploited by a malicious VM, no matter whether
# requiring user, root, or even kernel access in the VM, would be
# FATAL. In such situation (if there was such a bug in Xen) there
# really is no comforting that: "oh, but the mitigating factor was
# that the attacker needed root in VM!" We're not M$, and we're not
# gonna BS our users that there are mitigating factors in that case,
# and for sure, root/user isolation is not a mitigating factor.
# Because, really, if somebody could find and exploit a bug in the Xen
# hypervisor -- as of 2016, there have been only three publicly disclosed
# exploitable bugs in the Xen hypervisor from a VM -- then it would be
# highly unlikely if that person couldn't also found a user-to-root
# escalation in VM (which as we know from history of UNIX/Linux
# happens all the time).
# At the same time allowing for easy user-to-root escalation in a VM
# is simply convenient for users, especially for update installation.
# Currently this still doesn't work as expected, because some idotic
# piece of software called PolKit uses own set of policies. We're
# planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
# simple experiment: start 'xinput test' in one xterm, running as
# user, then open some app that uses PolKit and asks for root
# password, e.g. gpk-update-viewer -- observe how all the keystrokes
# with root password you enter into the "secure" PolKit dialog box can
# be seen by the xinput program...)
only do this when you make sure you don’t need root anymore
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?