Bluetooth is blacklisted to reduce attack surface. Bluetooth also has a history of security concerns. Bluetooth - Wikipedia
hotwater:
This is a very sharp decision. Many users use bluetooth for different purposes, like bluetooth speakers, mouses, keyboards, and other pieces of hardware.
Although bluetooth had many critical flaws, their core recommendations always admonish how to resist. Like the KNOB vulnerability which had a place on all bluetooth chips 1.0 to 5.1, core specs now say “enforce a minimum encryption key length of 7 octets for BR/EDR connections”.
It’s better to accurately follow the recommendations and not to cut the technology.
Was always wondering if we’d need two more packages. security-misc-vm (where blocking bluetooth makes sense) and security-paranoid (more experimental, more likely breaking things, probably non-default, optionally installed package).
That error is harmless and doesn’t do anything. It’s just because our kernel version doesn’t support this feature yet. There’s no point in reverting it.
That error is harmless and doesn’t do anything. It’s just because our kernel version doesn’t support this feature yet. There’s no point in reverting it.
The only point of reverting then is avoiding user confusion as this is a
prominent message during waiting for X to finally draw something.
Then we can change it to &>>${rootmnt}/var/log/sysctl-initramfs.log to log any actual errors in case of breakage but hide the unimportant ones from the user.
sysctl -p ${rootmnt}/etc/sysctl.d/*.conf >/dev/null 2> >(grep -v "sysctl: cannot stat /proc/sys/vm/unprivileged_userfaultfd: No such file or directory")
So only the unprivileged_userfaultfd error is hidden.
Something like this maybe. Though the actual error message to grep for is more similar to:
vm.unprivileged_userfaultfd is an unknown key
I didn’t note the exact one.
Also that snippet is broken. Added something else broken to it. (Just a single X in some sysctl config file.) That error would be hidden too with the current snippet.
Maybe redirect stderr to /var/log/sysctl-initramfs-error.log first, then cat and grep -v? Probably also simpler to read than >(...).
/etc/initramfs-tools/scripts/init-bottom/sysctl-initramfs is an sh script and >(...) might be a bash feature. Dunno if bash can be used in initramfs easy/sane[size, dependencies].
Looks different during initramfs in Whonix VIrtualBox 15.0.0.9.3-developers-only. Yes, I am sure. I was also surprised the error message is different in the fully booted system.
Maybe it is for now. Could we skip further error messages in future if required?
What’s the standard? I guess it is >>? But I am OK with your suggestion (new after each reboot) too. Otherwise we would have to add logrotate too. Full log over multiple reboot probably not worth that effort.
Should we use grep -v "unprivileged_userfaultfd" then? So the unprivileged_userfaultfd error is caught regardless of what the overall error message is.
Yes, we can just pipe grep into grep.
It’s probably >> but we won’t need old logs for something as small as this. The logs for the current boot only are fine.
Yes. That seems the most simple and robust solution. Good idea. I guess very unlikely any other error message would include that exact string unprivileged_userfaultfd and be hidden by mistake.