Impossible is one of these words⌠letâs start with
as an appVM is started from a templateVM you get an OS which system components have not been tampered with
However if there is a oneliner in your .bashrc which tampers with your binaries in /usr/bin or /usr/sbin you are pwned as soon as you start a bash in your appVM. As everyone can sudo a rootkit is reinstalled easily.
That really doesnât work unless you are able to load a rootkit, and if you can load the rootkit why not just do that directly, donât really understand the need to modify one of the system binaries.
Hmmm? curl is loading a script, the script is piped to bash, bash executes the script as user, user can sudo, root can tamper with all files and processes⌠in the context of the appVM of course.
That is just one way to hide. Lotâs of appVMs have a running /usr/bin/cupsd for instance. An attacker could add code to it and restart it. Or directly inject code to the process.
QubesOS and the distros used donât ship with IDS - not preinstalled at least. You can install some alienvault agent in your AppVM of course, but IDS didnât stop the solarwinds attack. I believe they flew under radar for 6 month or so. In big companies and institutions like the US state department. Small business and private people usually donât have an IDS.
Well, if you donât let any packets leave your machine
You canât protect yourself against something when you donât know what that something is. Observation is key.
If you canât trick the machine itself, trick the machines that it talks to.
Not impossible, but yes, you do have to leave A LOT of doors open to get persistence.
Youâd have to get dom0 to allow the connection out of the VM. Not impossible, but you have to be doing some pretty stupid things to allow it to happen.
Xen was potentially blocking access because your NIC wouldnât be able to interact with your CPU. Qubes OS compartmentalisation for the win!
Definitely true. Might be worth investigating whether âknown one linersâ could be scrubbed from AppVMs by dom0 on AppVM start. Could be mitigated.
Also true, but if it works, it doesnât really matter if itâs quick and dirtyâŚ.
Yes, provided itâs in the kernel tree. Or you could download a kernel module and build it with dkmsâŚ
Reminds me of Stuxnet. Malware which doesnât phone home but still impairs the work of the targeted devices.
I absolutly agree. One needs a blueprint of a virgin filesystem of the device for IoCs or normal network traffic when it comes to wiresharking traffic.
This outdated Xen exploit required to be root in one of the VMs. The OOB-check was very probably fixed in a timely manner. Also this ought to be mitigated in HVMs and PVHs. However I would like to strongly advocate against root access in VMs. In VMs which use minimal templates you can only become root by
[user@dom0 ~]$ qvm-run -u root <vmname> <xterm or blafoo>
This way one does not elevate privileges in the VM but decreases privilege from dom0 to root in the VM.
I donât believe an attack against dom0 really requires a lot of open doors. It is more like one or two. If an attacker has RCE on dom0 it takes something between 10 and 40 kilobytes of a base64 encoded bash script to open a bidirectional pipe to NetVM and initiate a satellite in the NetVM. Probably less.
Good to know. So there are policies in place which only root in dom0 can change?
I believe it used to be the same when I used to run archlinux on my laptop. Thatâs a topic I still have to investigate. And I have to take another look in my BIOS settings.
/home/user/.bashrc and /home/user/.zshrc could probably enforced and made ro by the template. oh-my-zsh-users might not like that⌠other environment scripts are in /etc/ I believeâŚ
Could a malware spoof or impersonate a valid kernel module?
Well, yeahâŚâŚ As long as youâre not using that particular model of centrifuge inside your Windows XP HVM on Qubes OS to enrich uranium, stuxnet shouldnât be problem for youâŚ.
âŚ.but just remember that itâs incubation period is 10-14 days before it kicks in, so if you are, maybe keep an eye on them
One or two of the right doors
Yep. Thatâd do itâŚ.
All of them. Root is the only one who can change any policies. But dom0 also has NOPASSWD sudo for the regular user, so if something did get in, it would still have free reign over the entire machine.
There is. By compromising this machine/wireshark. It is parsing all your traffic and while Wireshark might be a security related software it is not secure software.
As this is obviously not understood universally, let me state explicitly: if it is about Qubes OS it doesnât belong into âAll Around Qubesâ. This category is meant for topics that would be off-topic in the rest of the forum, but are of immediate interest to Qubes OS users.
Like âhow do I XYZ in Debian/Fedora/Linuxâ or âwhich browser is better in terms of security vs. privacyâ etc. ⌠stuff that is not specific to Qubes OS but clearly of intertest to Qubes OS users.
The above conversation is clearly on-topic in âGeneral Discussionâ, hence by definition off-topic here. Moving into appropriate category.