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.
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.
https://lists.debian.org/debian-security/2012/08/msg00016.html
With kernel lockdown we should be able to blacklist unused/uneeded modules. It is a more complete approach to cherry picking a few.
Do you mean this patch? A lot of those features are easily replicated or enabled by default.
We could make a list of all kernel modules and blacklist them while only allowing the ones we need. That’d be a lot of work though.
madaidan via Whonix Forum:
I just found out that we should probably be using
install (module) /bin/trueinstead of usingblacklistas the blacklisted module can still be loaded if another module depends on it.
Sounds good.
Do you mean this patch?
Yes.
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 bluetoothto some file in /etc/modprobe.d.
A systemd service can also be configured to run
rfkill block alland
rfkill unblock wifito block all wireless devices except WiFi.
Sounds good but only if not duplicated by lockdown.
It isn’t really duplicating code. A lot of the features are already in the kernel, they just need to be enabled with sysctl.
The only thing to do with modules in lockdown that I’m seeing is preventing them from loaded after boot. Does lockdown blacklist any modules?
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.
Should we blacklist all wireless drivers? This could be useful in VMs were wireless drivers wouldn’t be used. This can easily be done by running
for i in $(find /lib/modules/`uname -r`/kernel/drivers/net/wireless -name "*.ko" -type f | awk -F"/" '{print $NF}' | awk '{print substr($0, 1, length($0)-3)}')
do
echo "install $i /bin/true" >> /etc/modprobe.d/blacklist-wireless.conf
doneThreat model? How could anything (that does not have root compromise already) accidentally / by abuse load such a module?
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.
I don’t think this is a good idea for people who want to run Kali and Whonix. That would shut off a pretty useful usecase IMO.
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.
Good points. Blacklisting these probably isn’t that helpful.
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.
Thanks, merged!