I wonder how much secure (or less secure) BSD OS’s are…
I suspect any kernel written in a language where memory is managed manually is going to be more susceptible to terrifying exploits. Wonder long term possibility of Rust based OS’s…
Dont have much useful to add…just thoughts
If packages.debian.org, kernel.org or another trustworthy source would provide a Debian stable compatible APT repository with stable Linux kernels, that might be an option.
Otherwise this unfortunately is not actionable. Kernel re-compilation (with or without changed (security) settings) is too difficult and maintenance intensive given the current project resources.
Usability / reliability issues are also a risk.
related:
Refactor existing sysctl's for clarity, ease-of-use, and future-proofing.
Over the years many people have worked on sysctl's which has resulted in the files becoming somewhat disjointed, hard to read, and improperly/incorrectly documented (see README.md). This PR aims to bring a somewhat (opinionated) structure and order to the mess.
While I have increased the number of lines which might annoy experts, I have tried to provide some justification for these settings. Feedback is welcome.
There are no changes to the actual functionality of the code.
Refactor existing grub kernel parameters for clarity, ease-of-use, and future-proofing.
Add two (deactivated) kernel parameters to further reduce attack surface.
40_distrust_bootloader.cfg, 40_distrust_cpu.cfg, 40_enable_iommu.cfg, and 40_kernel_hardening.cfg into a single organised file 40_kernel_hardening.cfg.40_only_allow_signed_modules.cfg to 40_signed_modules.cfg.40_quiet.cfg to 40_quiet_boot.cfg.40_remmount-secure.cfg to 40_remount_secure.cfg.As with the post above, I aim to bring a some clear structure to the codebase (at the cost of increasing lines of code).
There are no changes to the actual functionality of the code.
I see now that the readme previously required a ton of context (looking at it after a while again), not well written, not easy to understand. So the readme improvements are appreciated!
Now I am wondering how to best handle the readme file. Seems hard to document these highly technical details for users. Seems hard to maintain such a readme file too.
Not sure it will be too much effort but perhaps the (part) of the readme should be auto generated based on metadata (residing in the comments) from the configuration file(s)? The we don’t need to write these in two places.
That would also allow to easily have both:
Because as it is now from reading the readme it is not clear to me what kernel setting is the related one.
Also a question what should be in the readme (or config files).
kernel.unprivileged_bpf_disabled=1)For the future, could you please set your editor to:
when saving a file? @raja
My apologies for this!
It is only when the first batch of merges starting coming in that I noticed this and was like “oh no” this is going to be bad given how many commits had already been submitted…
(Personally I have a very strong reliance on pre-commit for my repositories.)
I would always lean towards having README’s being human readable.
If people desire the exact kernel settings, they can (now) go to the clearly linked configuration files.
In my refactoring I have tried to ensure that the order of presented settings in the README exactly matches the order in the configuration files. We can preserve/enforce this moving forward. Furthermore, newer settings should ideally be placed at the bottom of the files which might make this easier.
I hope that this will help make it clearer which kernel setting is the related one. Additionally, I did try to make the README description very similar to the top line in the kernel settings.
I think presenting something along the lines of kernel.unprivileged_bpf_disabled=1 in the README will not help anyone as people knowledgeable in the matter are going to go to the configuration files anyway. To people new to kernel hardening, this will seem unintelligible.
Regarding the automation of README, I agree it is a good idea in terms of maintenance but I currently have no experience in the matter.
EDIT: Move post to a more appropriate location.
There may be another future optional kernel hardening parameter we should consider including but not changing from the default is the CFI implementation.
Firstly, I am not an expert of CFI systems [1].
Secondly since we are on kernel 6.1, we are currently using cfi=kcfi by default and this should not be modified. kCFI is a software-only implementation.
Next, as of kernel 6.2, the default CFI implementation has changed to be FineIBT which was developed more recently by Intel and requires more modern processors that support IBT (Indirect Branch Tracking) [2, 3]. There were a range of reasons for this change some relating to performance while others relating to security. FineIBT is a hybrid software and hardware implementation.
Fast-forwarding to now with the kernel 6.11 merge window happening it seems that “[s]ince FineIBT performs checking at the destination, it is weaker against attacks that can construct arbitrary executable memory contents” [4]. It seems that some people want to build systems with FineIBT disabled and revert back to kCFI for security reasons.
In relation to security, I am not overall sure whether pros and cons of using the new default FineIBT CFI implementation still outweigh that of the previous kCFI implementation. However, given these recent developments, it seems that there must be some doubt and that knowledgeable people want to go back for hardening purposes should cause us to pay attention.
Should we provide the kernel parameter option to set cfi=kcfi and succinct documentation in light of this so that both maintainers and users are aware?
This parameter also appears to only be available from kernel 6.5 onwards so will not be a concern till rebasing to Debian Trixie.
This should once again be entirely opt-in just like the choice to entirely disable the IPv6 stack.
EDIT: Add PR.