Updates to Desktop Linux Hardening Guide

[raja-grewal]

This PR updates several areas of the hardening guide:

• Very minor typo corrections and removal of white spaces,
• Add information regarding how to permanently disable CD-ROM modules not needed by the overwhelming majority of people,
• Add instructions to copying debugging scripts otherwise journalctl logs will be rather uninformative,
• Few corrections regarding what kernel parameters Kicksecure actually uses,
• Add a (very subjectively important) discussion regarding initial entropy generation and how to improve it since it is crucial to all hashes generated by the OS, and
• Add details regarding DMA mitigation that goes hand-in-hand with the earlier discussed module blacklisting.

Happy to receive any feedback. In particular, perhaps it would better to simply provide the Kicksecure boot parameters as they are more up-to-date and while still retaining Madaidan's excellent guide as a reference.

Sources are provided within the commits. I am also one of the contributors to security-misc and was responsible for many of the most recent kernel hardening commits building on very substantial earlier works.

[netlify]

✅ Deploy Preview for privsec-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	bbbd1df
🔍 Latest deploy log	https://app.netlify.com/sites/privsec-dev/deploys/63d7bc8214bcd7000844d9a7
😎 Deploy Preview	https://deploy-preview-81--privsec-dev.netlify.app/posts/linux/desktop-linux-hardening/index.html
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[TommyTran732]

From a quick glance it looks good. LMK when it's ready for review.

[wj25czxj47bu6q]

I started a review but ended up correcting a lot of typos from Tommy's original post, which are not appropriate to address in this PR. I will move those to a separate PR and then publish my review here.

[wj25czxj47bu6q]

Sorry for the delay. Here is my review, mostly minor things.

Some conflict resolution with #93 will be needed.

[randomhydrosol]

Regarding attestation, UKIs don't really do that. You are just attesting early-boot with it. The moment the kernel boots the rest of the code is executed without any checks

Another problem with UKIs is that they have no .sbat support (so are users forced to attest every boot to make sure they aren't being downgrade attacked?) and the simplification of the boot process (using systemd-boot instead of grub) doesn't allow creating a proper root of trust using features like the intel TXT. The intel TXT is mandatory to get a root of trust

1. We can't just go back to grub, too bloated and causes more security risks than it fixes
2. A bootloader that supports DRTM to create a proper root of trust is needed. Without it you're trusting your system firmware for attestation which has repeatedly been proven to be unreliable
3. Need downgrade protection for the entire boot path. Currently downgrade protection is only present up to the last bootloader
4. Tboot/DRTM on linux doesn't support native UEFI nor secure boot. Support needs to be added
5. Even if tboot has limited uefi boot capabilities, there is no linux bootloader that saves/restores efivars for use by the trusted OS/VMM so the OS can't access efivars at all
6. Since no firmware is present in the trusted environment created by the DRTM event, impossible to update secure boot dbx without bootloader support. At present, no linux bootloader supports this
7. No dm-verity support in linux desktop yet
8. If users have to attest the system every boot to ensure they aren't being downgrade attacked, they all already in a serious mess by the time they find out because the system has already booted, data is no longer at rest

[randomhydrosol]

A few other things that are easy to verify on windows:

1. The presence of the windows security mitigation table in ACPI -> it's in msinfo32, under "virtualisation based security available security properties" as "SMM security mitigations 1.0". If present, bios vendor is following at least the baseline security practices for SMM code
2. UEFI MAT compliance -> enable the group policy to only enable hypervisor protection of code integrity if the uefi memory attributes table is available and reboot. If core isolation is still enabled, UEFI memory is strictly W^X
3. Secure MOR -> in msinfo32, same place as the windows security mitigation table. It's named "Secure memory overwrite". You need to enable RESET_ATTACK_MITIGATION in linux

In addition, most people don't set up the TPM correctly on linux. Pressing "clear TPM" in the windows security app or tpm.msc will set up the TPM with reasonably secure parameters and it can be used by linux right away

[randomhydrosol]

Not sure what i think about sbctl. It relies on the secure boot keys being stored on the same system that's going to be verified. That's a really bad idea

[randomhydrosol]

Please note that we should also add the information under bitlocker countermeasures to the DMA protection guide. Just note that instead of setting the thunderbolt setting to user authorization, it should be set to secure connect instead for marginally better security

[wj25czxj47bu6q]

FYI @randomhydrosol I think most of your comments target the existing guide rather than the contributions in this pull request

[TommyTran732]

Anyway, i don't really get the point of distrusting the CPU. Android uses the cpu and uefi for entropy, so does windows

If this is good enough for them, why is this a problem for us?

It is just one of the configurations from Kicksecure. I am not sure how it affects entropy in reality tbh.

[TommyTran732]

Not sure what i think about sbctl. It relies on the secure boot keys being stored on the same system that's going to be verified. That's a really bad idea

It is just the lesser evil right now imo. At least an adversary cannot just magically modify the UKI/bootloader and sign it. It is still better than having no verification for the initramfs at all.

[raja-grewal]

Firstly, thanks for your extremely detailed reply. You have taught me many new things about modern DMA infrastructure. My reasoning for recommending these settings was heavily based existing recommendations in KSPP and Madaidan and also the previous acceptance of these settings into Kicksecure/Whonix.

I also agree that the bulk of DMA protection is sourced from system firmware implementation. However, is there any harm done from these kernel parameters even though verification of their success is troublesome? For situations where the firmware is terribly implemented, wouldn’t this still be beneficial?

I am also in complete agreement that the general public should be using secured-core hardware where possible. This however may not be feasible due to a myriad of factors such as cost, location, compatibility, and privacy concerns. For example, in Australia it is quite difficult to find any retailers selling these devices in quantities needed for personal use. Instead, they need to be imported from overseas which raises warranty concerns. Additionally, while people certainly shouldn’t expect secured-core level security from custom builds, I believe they should still be entitled to all reasonably feasible mitigations.

The good is not the enemy of the perfect.

While I understand and totally agree with your strong advocacy modern secured-core infrastructure, this PR is very specifically about linux hardening and so I suppose the goal is to maximise security for those people that will not and/or can not switch to Windows.

Regarding the point of distrusting (not crediting) the entropy generated by the CPU and UEFI, this is much more a forward looking mitigation rather than being associated with existing flaws (see links in Madaidan). At the cost of lengthier boot time, the all generated cryptographic keys are ‘more’ random which can only be a positive.

See the exact definitions of the kernel parameters (or compile time options) at the bottom of the hyperlinked LKML page when I wrote “both the CPU and bootloader should be distrusted”.

I can only speculate as to why Android or Windows credit both sources to the entropy pool. Two reasons come to mind, firstly as aforementioned, quicker boot time which the overwhelming majority of end-users would consider favourable. Secondly, this concern is not a very low hanging fruit and exploitation of issues related to reduction of entropy quality is not trivial. This is because both of these entropy sources are mixed with others. Overall, the distrust settings just ensure that if any future issues are discovered in devices using closed-source random number generators, the cryptographic keys previously generated by these devices are strictly equivalent or more robust that if these settings had not been utilised.

Moving on to UKIs. I agree that there are many limitations especially since you are generally only attesting early-boot. There is certainly no disagreement that the Linux security model is lagging further and further behind the contemporary state-of-the art. However, again, for a Linux hardening guide we are limited to using Linux and improving it as much as we possibly can.

While attesting only early boot is a far from ideal, it is still better than nothing. Suppose the disk is encrypted but the boot partition (as is often the case) is unencrypted and so modification of the UKIs is feasible especially if access to the physical disk is possible. Next, suppose if the UKI has then been tampered with. Even though rest of the code will then be execute normally, at the very least the user will hopefully be notified upon booting that there is a problem. While this is logic is largely circular, wouldn't the possibility of alerting the user to a compromise be better than the non-existence of this functionality?

Though again I look forward to proper root of trust being implemented even though it is probably going to take quite some time. On the upside, proper use of TPM does appear to be growing with newer versions of systemd. Also thank you for informing about RESET_ATTACK_MITIGATION, I will need to investigate this further.

Finally, regarding sbctl, I agree that storing the keys on the device being verified is rather circular, but is it still not better than having absolutely zero verification for the initrds/UKIs?

I am not completely certain that I have addressed all your comments so please let me know if that is the case.

[wj25czxj47bu6q]

Thank you for the extremely detailed response. I want to review the PR again since it has been quite some time, but I now see your logic in the entropy source distrusting.

[raja-grewal]

No problem, the topic has many subtitles. Regardless, I look forward to your revised thoughts.

[raja-grewal]

Regarding the enabling of RESET_ATTACK_MITIGATION for secure memory overwrite in linux (introduced here):

As the config defines, it depends entirely on the EFI stub and firmware and so is largely outside the control of typical users using their existing hardware.

The current master branch of the kernel does appear to attempt to pass the erasure request [see here 1, 2, 3, 4].

The current 6.0 branch of linux-hardened also acts similarly [see correspondingly here 5, 6, 7, 8].

Overall, as you explained, this is clearly an important requirement and so users should seek devices that support this functionality.

[wj25czxj47bu6q]

Hi @raja-grewal, sorry for the delay. Please review and accept our Contributor License Agreement so we can move forward with your pull requests.

[wj25czxj47bu6q]

I have been busy researching IOMMU and DMA protection based on this PR and randomhydrosol's comments above. Here are some resources I found to be helpful:

• IOMMU Groups, inside and out by Alex Williamson
• intel IOMMU driver analysis by Terenceli
• Avoiding gaps in IOMMU protection at boot by Matthew Garrett
• And of course the kernel parameter docs

Hopefully these are helpful to someone.

[wj25czxj47bu6q]

I think we are nearly ready to merge this; I just have 3 nitpicks. Please also take a look at my direct commits, including the merge commit, to make sure you are happy with my changes there.

[raja-grewal]

Overall, looks good enough to be made public in my opinion. While I could suggest further modifications, this would likely result in a perpetual process of revisions.

At this point in time I think it would be wiser to merge and wait for potential feedback from the broader community before continuing the never ending cycle of nonstop improvements.

[wj25czxj47bu6q]

I agree that this is now ready to merge. @TommyTran732 please do a final review as the primary post author.