Whonix Wiki Download Docs News Support Tips Issues Contribute DONATE

Kernel Hardening

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.

1 Like

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.

1 Like

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
https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html?highlight=trust_bootloader

Also the discussion:
https://lkml.org/lkml/2022/6/5/271

1 Like

Yes.

Minor stylistic question: Actually a bit weird there is a separate config file https://github.com/Kicksecure/security-misc/blob/master/etc/default/grub.d/40_distrust_cpu.cfg 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:

https://systemd.io/RANDOM_SEEDS/

1 Like

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

iommu.passthrough=0

iommu.strict=1

See IOMMU_DEFAULT_DMA_STRICT in:

and kernel command line options in:
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings

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

randomize_kstack_offset=on

See :
https://lkml.org/lkml/2019/3/18/246

Also look to making a note that

slub_debug=FZ

should perhaps be disabled due to:

https://madaidans-insecurities.github.io/guides/linux-hardening.html#boot-parameters

Regarding entropy, I am very far from an expert on its unbiased generation, regardless, I was under the impression that since kernel v5.4 and v5.6 it is pretty ok by default.

Using the command line as source is a very interesting idea and would definitely help. Has any progress been made on its development?

1 Like

Yes, please. Also add the links please.

Why commented out?

Yes, please comment out and add the comment.

No progress unfortunately. If there is, I try to always keep the related forum threads (or preferably wiki if already there) updated.

Yeah. Complex topic.
Related:

1 Like

Please add the the “normal” file.

GPU passthrough is quite complicated for users to do, not documented, not popular? Not a good reason to not do this? I.e. these options should be set?

1 Like
1 Like

Does this work for your on the host operating system?

1 Like

Are you having issues?

On Arch with systemd all of these have been working fine for me for a while.
Linux pc 5.18.10-hardened1-1-hardened #1 SMP PREEMPT_DYNAMIC Fri, 08 Jul 2022 20:53:33 +0000 x86_64 GNU/Linux

I will investigate more thoroughly.

1 Like

Not tested yet.

1 Like

Could you please update the readme as well?

net.ipv4.ip_forward=0

That’s always a sane default everywhere anyhow? No distribution would enable that by default? And if user set, it should not be touched?

1 Like

Agreed it always should be the default, I just put it in to be safe. Would you recommend reverting that commit?

1 Like

Yes, please. Because if we start setting all the values which are default anyhow (and unlikely by any sane project to ever be changed), then the settings file could quickly become unmanageable huge.

1 Like

No problem, commit reverted and the readme has been updated.

1 Like

Debian’s lintian does not like use of folder bin/disabled-module-by-security-misc/.

################################################################################
E: security-misc: subdir-in-bin bin/disabled-module-by-security-misc/
N:
E: subdir-in-bin
N:
N:   The Filesystem Hierarchy Standard forbids the installation of new
N:   directories in /bin.
N:   
N:   Refer to Filesystem Hierarchy Standard (/bin : Essential user command
N:   binaries (for use by all users)) for details.
N:   
N:   Severity: error
N:   
N:   Check: files/hierarchy/standard
N:
################################################################################

If am not mistaken, this could be fixed by moving the folder from binusr/bin with no change in code required. Though if we want to keep it in bin it might just be easier to unpack the directory and rename the files. What do you think?

I prefer the second approach. Should I send a PR?

1 Like

No, lintian does not like the subdir. I.e. having a dir inside /bin (or /usr/bin).

Ok so I can add individually the files without the folder?

1 Like

Yes, that would be good.

1 Like