I just found out that we should probably be using install (module) /bin/true instead of using blacklist as the blacklisted module can still be loaded if another module depends on it.
I just found out that we should probably be using install (module) /bin/true instead of using blacklist as the blacklisted module can still be loaded if another module depends on it.
A lot of those features are easily replicated or enabled by default.
Please donāt replicate / duplicate code without strong rationale. If
lockdown can work for us, we should keep lockdown responsible to keep
maintenance effort at our side low in the long run.
It may be useful to blacklist some wireless devices to reduce attack
surface.
For example, to blacklist the kernel modules for bluetooth, add
blacklist btusb
blacklist bluetooth
to some file in /etc/modprobe.d.
A systemd service can also be configured to run rfkill block all and rfkill unblock wifi to block all wireless devices except WiFi.
Sounds good but only if not duplicated by lockdown.
Iāve looked at the lockdown code and all it does is change 3 sysctl settings, two of which we already use (in security-misc) and the third one just prevents modules from being loaded after boot which isnāt that much of a security gain.
Either, Iām missing something massive or lockdown is mostly useless for us.
It prevents anything not needed by the system from loading. Bear in mind we cannot anticipate all hardware configs for Whonix hosts to set these parameters permanently by default. This will cause problems and users to complain why hardware X is not working.
There is no added benefit for this IMO because malicious code already has plenty of choices when running as root than loading extra modules. (user mode code canāt load modules and needs privilege escalation which isnāt too hard on current Linux systems anyway).
It only prevents them from being loaded after boot. It doesnāt blacklist the modules so they can still be loaded. Preventing modules from being loaded after boot can be done by setting kernel.modules_disabled=1 with sysctl instead of installing a whole new program.
Modules like bluetooth modules will still be loaded at boot when used with lockdown as it does nothing to block those.
It could be loaded at boot. E.g. if someone has added a wireless adapter to the VM, the driver would be loaded at boot.
Some other services that run as root may also load them.
If malware (that was locally installed) gains root, it can load those modules so an attacker can remotely access the machine without needing to modify the firewall.
Not understanding the threat model / security benefit yet.
If someone attached a wirelesss adapter to the VM (not happening by accident), then they probably want it functional, so this functionality would just be an obstacle for those.
Examples needed.
Then it is game over anyhow?
I donāt see how the module load could do any worse then doing other things.
Which again needs a wifi adapter attached already, and if one has been attached, itās not due to accident.
Do you mean unsolicited incoming open server ports?
Most people are behind NAT routers or or 4G shared IP with NAT nowadays anyhow.
Looks good. Please document in case someone might want it for some reason, though I donāt see why anyone would bother when Wifi is faster and has a longer range.