No, the initial boot drive doesn’t depend on what the chainloaded kernel on the main drive does.
madaidan:
used within Whonix
Note, that security-misc package is unspecific to Whonix. A general package.
security-misc will be installed by default in Kicksecure and on Whonix-Host. Therefore must not break general hosts.
Can you implement a new vm-hardening package?
3 Likes
I doubt CD-ROMs would be used within Whonix and the CD-ROM kernel driver has had some vulnerabilities before such as CVE-2018-11506 .
How to exploit, how to make the kernel load the module?
Irrelevant in a VM without cd-rom drive?
A VM without cd-rom drive won’t have the module. Won’t need the config therefore?
and a VM with cd-rom drive should work out of the box because the drive was manually added?
2 Likes
I just tested it and live mode works fine with squashfs blacklisted.
Patrick_mobile:
Note, that security-misc package is unspecific to Whonix. A general package.
security-misc will be installed by default in Kicksecure and on Whonix-Host. Therefore must not break general hosts.
It can easily be removed for things that need CD-ROMs. I imagine most would be using USBs instead anyway.
No, it’s loaded by default whether you add it or not. Run lsmod
and you’ll see the cdrom
and sr_mod
modules already loaded.
Patrick
September 2, 2019, 5:18am
6
lsmod | grep cd
Shows nothing for me in a Qubes VM.
1 Like
Patrick
September 2, 2019, 5:41am
7
madaidan:
We can blacklist a bunch of uncommon filesystems by creating a file in /etc/modprobe.d with
install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
install hfs /bin/true
install hfsplus /bin/true
install squashfs /bin/true
install udf /bin/true
This blacklists cramfs, freevxfs, jffs2, hfs, hfsplus, squashfs and udf.
How could an attacker make the kernel load such a module?
Similar as above:
A sysadmin having attached a device which contains such a file system and wanting to mount it, should be able to.
Without attempting to mount such a device, no module will be load.
No module load → no exploitation attempt using that module possible.
Or are there other ways a non-root user may cause loading such a module?
2 Likes
Live mode does not use squashfs, but the host/iso does which will fail if the module is not loaded.
Instead of blacklisting you could also skip compiling them into the custom kernel. I guess the cloud kernel from the debian repo won’t have most of those and other stuff. But I also could not get it to work.
Why just stick to non-root?
2 Likes
Patrick
September 2, 2019, 8:11am
9
Because root access means game over if malware gained root. The attacker has way too many ways to compromise the system in persistent ways. Root should be allowed to load the module / mount any disk.
2 Likes
Modprobing stuff would be one of the options for a kernel exploit. Certainly not the only one but at least one options less for the attacker.
Edit: We also have apparmor which limits what a user, including root, can do.
2 Likes
Patrick
September 2, 2019, 8:25am
11
Algernon:
Modprobing stuff would be one of the options for a kernel exploit. Certainly not the only one but at least one options less for the attacker.
Edit: We also have apparmor which limits what a user, including root, can do.
Larger discussion. Created Untrusted Root - improve Security by Restricting Root for it.
2 Likes
It’s there for me in Virtualbox. Virtualbox might add CD-ROM support by default while Qubes only adds the bare minimum. If so, is there a way to disable it in the Virtualbox ovas by default?
Patrick:
A sysadmin having attached a device which contains such a file system and wanting to mount it, should be able to.
Without attempting to mount such a device, no module will be load.
An attacker could attempt to mount something containing the filesystem which will load the module.
Things like thunar-volman and udisks allow unprivileged mounting.
Root can just remove the file that blacklists these modules anyway.
As per linux - Methods root can use to elevate itself to kernel mode - Information Security Stack Exchange , we should disable CPU MSRs.
MSRs are only exposed when the msr
module is loaded so we can blacklist that module to prevent them from being abused.
1 Like
Does this break virt-detect?
1 Like
Patrick
November 28, 2019, 3:45pm
16
Good point but even if it does, that is only required by two features.
[1] power-savings-disable-in-vms
[2] whonixcheck warn against unsupported virtualizers
Non-essential features. [1] could be implemented in another way.
Kicksecure has both, VM and host packages:
kicksecure-cli-vm / kicksecure-cli
kicksecure-xfce-vm / kicksecure-xfce
Whonix doesn’t have that yet and it’s difficult to make the conversion for existing users. (Since this is the “top level” meta package.)
[2] might be lost but I guess that is a feature reduction we can endure.
1 Like
No. MSRs have nothing to do with that.
1 Like
I’m pretty sure they do because when i blocked access to them using libvirt it broke hypervisor detection, but @Patrick explained it’s not a big deal.
1 Like
No, you can even test it yourself by running systemd-detect-virt
and seeing the msr
module isn’t even loaded.
2 Likes
Good to know. Then go for it
2 Likes