Qubes-VM-hardening
Qubes-VM-hardening copied to clipboard
tasket
port to plain Debian (non-Qubes)
Wondering if this could be useful for Debian too.
(Not only Debian TemplateBased AppVMs in Qubes. I mean "normal" Debian systems without Qubes.)
More operating system compatibility could get more eyes on this. Then the Qubes support would ideally be nothing too special.
It is already easy to get a Debian boot menu which has a live and a persistent mode using grub-live.
Similarly I am planning to add a boot menu entry which allows the user to boot with root access or without root access.
A system booted without root access could benefit from the same mechanisms that "Qubes"-"VM"-Hardening is using. We could scratch the "Qubes" as well as the "VM" part as this should be possible on any Debian host or VM or any Linux (etc.).
I might even implement all of this myself into the security-misc (or separate) package. Debian packaging works already perfectly and Fedora / Qubes packaging is on the way too (https://github.com/QubesOS/qubes-issues/issues/1885).
So if you are wondering why I am creating lots of tickets and/or asking lots of questions lately, then this post will explain my motivation.
I've thought about this in the past, but wasn't aware of grub-live so I assumed it would only involve making /home files immutable. But maybe a whitelisting, etc. would also be valuable to a 'live' instance.
If you end up putting some of these features into security-misc, I could add an installer exception for Whonix templates so there is no collision, or put a notice in the readme to that effect. For the time being, however, I'd like to continue here with Qubes-VM-hardening's narrower scope of whitelisting and re-enabling auth, possibly making that work in Qubes-Whonix.
tasket:
I've thought about this in the past, but wasn't aware of grub-live so I assumed it would only involve making /home files immutable.
Actually all files including root. Not just /home. Root compromise could circumvent that but a combined no-root boot mode could reduce that risk (require root escalation exploit).
But maybe a whitelisting, etc. would also be valuable to a 'live' instance.
If you end up putting some of these features into security-misc, I could add an installer exception for Whonix templates so there is no collision, or put a notice in the readme to that effect.
Good. I'll back to that when time has come.
For the time being, however, I'd like to continue here with Qubes-VM-hardening's narrower scope of whitelisting and re-enabling auth, possibly making that work in Qubes-Whonix.
Alright. No need for monoculture. I'll keep supporting / following this project. More eyeballs in this area are certainly always helpful.
What's the rationale of making user files immutable?
chattr -R -f +i $chfiles $chfiles_add $chdirs $chdirs_add
After reboot, malicious modification would be undone anyhow.
Malware being active in the current session could stay resident so or so. It does not have to require any dotfiles for that. And after reboot, gone so or so. So currently I don't see the gain by chattr +i . Could you please kindly explain?
vm-boot-protect protects against unprivileged malware persistence during startup. Its basic method is admin-controlled +i immutable...
This helps prevent unprivileged malware staying active, either through some user auto-run ability or shimming (altering PATH, for example). Since a user can delete then replace any file in a folder they own (even files owned by root!), immutable is needed to stop this. It could make a difference (at least with initial post-startup state) in the default case where /home contents are not quarantined/replaced.
vm-boot-protect-root protects against privileged malware persistence during startup. Its basic method is file quarantine...
If we assume that privilege escalation is attained, then /home becomes more of a problem as indeed +i won't stop such malware. But that's why I'm making it easier to add /home to quarantine (i.e. privdirs).
(BTW "so or so" isn't an expression I'm aware of; I don't know the meaning of those statements. "so and so" usually means 'some other unimportant person'.)
(BTW "so or so" isn't an expression I'm aware of; I don't know the meaning of those statements. "so and so" usually means 'some other unimportant person'.)
I see. Too localized expression which doesn't translate. With "so or so" I meant "in any case".
Rewrite for plain Debian (non-Qubes) is in process. Early version below. Not ready for testing yet. Operating system integration not done yet.
https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/virusforget
Could you have a look please to see if you see any obvious holes in this script?
virusforget seems to operate on a principle of comparing live files with backup copies.... I probably missed it, but I didn't see where virusforget/backup was being protected.
Also, I learned that symlinks don't take attribs like immutable (sigh). I plan to work around this with something like find -type l + mount --bind.
tasket:
virusforget seems to operate on a principle of comparing live files with backup copies....
Yes.
I probably missed it, but I didn't see where virusforget/backup was being protected.
It's an excellent point I did not consider yet. It resides in /home/virusforget. Only accessible by root.
But this then also means that a root compromise in Qubes TemplateBasedVM which was specifically crafted to circumvent VirusForget would succeed.
How does Qubes-VM-hardening protect against that? Basically that configuration has to be done in TemplateVM and therefore resides in root image outside of reach of malware inside TemplateBasedVM?
It's an excellent point I did not consider yet. It resides in /home/virusforget. Only accessible by root.
The /home/user dir is owned by user, so virusforget (-i mutable) can be renamed or even deleted also by non-root attacker. Then it could be replaced with changed files.
(root compromise) How does Qubes-VM-hardening protect against that? Basically that configuration has to be done in TemplateVM and therefore resides in root image outside of reach of malware inside TemplateBasedVM?
Yes. User has to decide they want to protect /home against root attacks. The tools for that are adding /home to quarantine (privdirs) and/or using whitelists or deployment files from /etc/default/vms. Alternately, they could simply generate a sha256sum list for /home/user contents.
Another interesting approach (in future) might be to automatically create a sha256sum list specifically for chfiles and chdirs, or to copy those files into /etc/default/vms for deployment. IOW, help the user with this type of advanced configuration.
The philosophy behind the two available levels (vm-boot-protect and vm-boot-protect-root) and the user having to choose advanced protection of /home is that the rest of /rw is normally executed as 'root' at startup, while /home contents are normally executed as 'user'. If non-priv user has an escalation exploit they can use from /home startup scripts, then they can persist the escalation... but only until the vulnerability is patched.