Interesting tool, anything that can contributed to it?
Was posted here: kernel recompilation for better hardening
That comment needs an update.
debian bug report: Please reconsider enabling the user namespaces by default
It seems that next debian version will have unpriv user ns by default.
Related to Linux kernel user namespaces:
kernel.unprivileged_userns_clone=1 in Debian
bullseye and above.
bubblewrap will be no longer suid by default.
What do we do with
apt-cache show security-misc, potentially packages.debian.org APT package repository web interface for deb.whonix.org) and
debian/control so it doesn’t have to be duplicated? Delete / avoid creation of
I think it should just contain a basic description and a link to the Github repository for more detailed information.
@madaidan GCC 12 just added a security compile time option to auto initialize auto variables. Don’t know if this is a problem in the kernel code these days anymore. Also have no idea how this can affect areas of the code related to rngs. Might be useful for other binaries we compile however.
The STRUCTLEAK GCC plugin already automatically initializes variables although this will likely be stronger and less hacky.
Now that Debian and other distributions like Arch Linux are starting to relax their user namespace restrictions (but still keeping the sysctl for users to manually configure), we should preserve them in security-misc by setting
kernel.unprivileged_userns_clone=0. User namespaces are still a huge risk and a minimal setuid binary where we can tightly control the attack surface exposed is superior by far. Unfortunately, upstream doesn’t seem to care.
However, we will need to make bubblewrap setuid ourselves since the package is not setting it anymore (at least in Debian). Should we just add
chmod u+s "$(which bwrap)" in the postinst script and add some details in the readme?
There is also an issue when running Chromium in sandbox-app-launcher since no_new_privs will disable the setuid fallback. Ideally, we could probably add a way to whitelist which binaries are permitted to use unprivileged user namespaces (maybe contribute to linux-hardened). Firefox is also affected, but instead, its sandbox silently fails without crashing and lies to the user about the status of the sandbox because Firefox is terrible.
I wanted to port this to dracut (replacing initramfs-tools with dracut) but it seems it’s not needed. Seems like dracut has early sysctl settings by default.
Some new things grsecurity/PaX has been doing in kernel hardening since they went private:
- GRKERNSEC_SUID_NO_UNPRIV_EXEC — prevent SUID root applications from mmaping/execing files world-writable or not owned by root.
- AUTOSLAB — conversion of k*alloc allocations into their own caches
- PAX_PRIVATE_KSTACKS — I have no idea
It’s worth noting that GRKERNSEC_SUID_NO_UNPRIV_EXEC prevented exploitation of CVE-2021-4034, but it really isn’t as important as something like AUTOSLAB.
Arguably as well as improvements in kernel settings that can be applied to Whonix now, any devs with skills like madaidan (come back man!) could be contributing to the KSPP project led by Kees Cook. That way security improvements will apply to all Linux users going forward:
If you read through some of these issues, it brings to mind that it appears to be a big security advantage to shift to higher kernels once they become stable, because many improvements are only available in later releases.
For Whonix I gather that would mean shifting to later stable kernel releases sooner rather than later i.e. instead of staying on kernels like 5.10 for years at a time. For Qubes, that would mean upgrading the dom0 kernel to later stable versions whenever possible.
While we distrust the CPU for initial entropy, should we also consider distrusting the bootloader?
Thoroughly auditing the initial grub boot seed generation process is non-trivial. Even if we assume the current versions are solid, future versions could potentially become compromised.
See the kernel parameter random.trust_bootloader
Also the discussion:
Minor stylistic question: Actually a bit weird there is a separate config file security-misc/40_distrust_cpu.cfg at master · Kicksecure/security-misc · GitHub just for that? Or actually good that it’s split to make review easier and perhaps allow advanced users to more easy override such settings? Where should the distrust bootloader config file be placed? An additional file? Could be. I guess it does not matter much.
Could you please send a pull request?
I haven’t found such a feature in grub. Would be interesting but just a sideline.
According to Random Seeds it seems that is for now only related to EFI booting.
But also unspecific to grub. Kicksecure / Whonix shouldn’t be dependent on any specific bootloader such as grub for security if it’s so easy to avoid by setting a kernel boot parameter.
Sideline: It has some interesting quotes that I will cite and soon add to Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND.
Related but different:
(It’s kernel command line as source of randomness. Not bootloader directly.)
Related probably interesting reads, maybe further inspiration for hardening:
I am also not to sure where exactly the distrust bootloader should go.
My wording here was extremely poor, what I meant to say was basically how grub or any bootloader acquires random seeds.
There are also two other boot parameters that come to mind. More DMA blocking using
See IOMMU_DEFAULT_DMA_STRICT in:
and kernel command line options in:
Using these two will likely cause issues with GPU passthrough.
Also see page 11 of:
Additionally building on this, when moving to more recent kernels v5.14+ I see the impact of two boot parameters.
Perhaps we should include and comment out
Also look to making a note that
should perhaps be disabled due to:
Using the command line as source is a very interesting idea and would definitely help. Has any progress been made on its development?