search

anthraxx / linux-hardened

Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening
Other
554 stars 55 forks source link

LKRG in-tree @ 1ab4d32f6e20dec8ac7fa029 #56

Closed sempervictus closed 10 months ago

sempervictus commented 3 years ago

"LKRG performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel."

In practice, this is a kernel-mode rootkit working to validate the runtime integrity of the kernel into which it loads instead of subverting it. It leverages its ring0 position to try and perform detection of malicious activity and provides several presets for runtime configuration as well as granular sysctls to fine-tune operation.

Generated using openwall/lkrg/blob/main/scripts/copy-builtin.sh, which should be used to refresh the source tree every once in a while as LKRG is under active development. Background/commits for the script in openwall/lkrg/pull/31.

Testing (on the 5.4 branch): Weeks of abuse on loaded systems running various test suites. Currently runs in production on dozens of systems serving KVM, container, storage (ZFS, iSCSI), and networking functions. Our kernels build-in a ton of out-of-tree code, covering xtables, LVS, PF_RING, and other projects - we've not seen any issues with those in our testing/usage either.

Bernhard40 commented 3 years ago

What do you gain by having this in tree instead of separate module to cover maintenance cost?

madaidan commented 3 years ago

@Bernhard40 If it's built-in (=y), it's a bit harder to bypass as you can't just unload the module anymore and it will always be active. It will also make it usable in kernels with CONFIG_MODULES=n (to prevent an attacker from loading malicious modules or to improve CFI granularity). However, I do not believe that this should be added to linux-hardened and instead, should be added to downstream projects if they want this using the mentioned script. I don't think it fits here.

sempervictus commented 3 years ago

Building it with the kernel means signing with the build-time key as well. Far as where it belongs, this is about as good as it gets IMO so that all downstream consumers get the module for optional insmod and those who want it built-in can y it downstream. Secondly, because the repo is called linux-hardened - which is the kernel (whereas hardened_malloc and friends belong in the relevant userspace repos of potential downstream projects). Having the ability to load runtime integrity verification is a dynamic hardening measure much like the C changes and GCC plugins are static hardening.

sempervictus commented 3 years ago

@thestinger: If you happen to see this, LKRG is now set up to be built directly into the kernel and run using a synchronous late initcall to permit all of the ro after init stuff to settle down a bit before sampling hashes. Might be a good addition to GrapheneOS to help deal with kernel-level LPEs against the SELinux context. Figured i'd point it out here since there are a bunch of kernel trees in the GrapheOS account which could benefit from them, and i didn't want to fork and pull on each one if this is of no interest.

sempervictus commented 10 months ago

LKRG is unfortunately incompatible with LTO and kCFI due to its probing semantic. With LLVM16 being out, proactive hardening via compile-time mechanisms is preferable to post-exploitation response attempts via probing.