hardened-kernel disables kprobes as they can add significant attack surface — it allows debugging most of the kernel and potentially gathering sensitive information.
It seems that LKRG relies on this but I’m not sure exactly to what extent. @Patrick could you ask on the mailing list about what kprobes are required for and if they could be replaced? I’d be reluctant to enable them in hardened-kernel.
Lockdown restricts kprobes too so maybe lockdown would also break LKRG?
As soon as LKRG is loaded in the system, none of the .text section modifications is allowed. This is also true for the official Linux APIs which sometimes does patch(!) it. One of the examples might be kprobes interface. It is injecting 0xCC instruction on the monitored function. That’s why all modules using kprobes must be loaded BEFORE LKRG.
LKRG leverages *kprobes interfaces to “lock down” all possible ways of interacting with processes. As an end-result no one from user-space is able to interact with the process protected by LKRG. There is one exception for compatibility reasons:
Protected process might fork itself and for the security reasons if this ever happens, child must be automatically protected as well. Because mother and child often must communicate with each other, every protected process might interact with each other using official API. Exactly the same as non-protected processes in Linux. In practice LKRG creates a “new group” of processes which are isolated from “normal” Linux processes. These “new” processes have higher privileges since they can normally interact with all types of processes (including PP), where normal process has no access to the Protected Processes at all.
Self-defence
Implementation of Protected Features relies on *kprobes interface.
Counting lines containing kprobe in LKRG source code.
grep -r kprobe | wc -l
253
It indeed does. Though, I don’t immediately understand if that’s still the case in newer kernels. Also difference between lockdown in integrity vs confidentiality mode. As mentioned here:
Can you make head or tail of it?
Does above make clear what these are used for?
If they could be replaced, well, I am not sure I am the right proxy to ask that. I am not sure I am the right guy to defend an argument versus kprobes.
I know mailing lists are painful to interact with.
However, LKRG is also active on github (as above ticket indicates). Could you try please posting a feature request there?
ftrace/kprobes can allow messing with a lot of kernel code to gather sensitive information or hook parts of the code (like LKRG does). Disabling it would be deterministic attack surface reduction whereas LKRG is a probabilistic protection, i.e. it can be bypassed without too much effort if malware is aware of it. However, LKRG does cover a lot more than disabling ftrace/kprobes would. LKRG could theoretically be better but that’s assuming that it’s not bypassed in the real world.
It’s hard to determine exactly which should be preferred but I think I might enable ftrace/kprobes for LKRG support with a wiki section explaining the rationale.
What would be nice is a Yes or No prompt within the hardened-kernel install script. Perhaps the prompt would say would you like to enable ftrace/kprobes for LKRG support and give the paragraph above as a disclaimer. Based on your answer, it would load the proper config file.
Perhaps if you choose Yes to enable ftrace/kprobes for LKRG support, the script would install LKRG as well so it works out of the box with the hardened kernel.
Or simplify it by adding --lkrg to either --vm or --host when you compile the hardened kernel to match your set it and forget it design.
Please keep things non-interactive. Otherwise breaks non-interactive upgrades. Settings folder in /etc seems more appropriate. A top goal is to keep this integrated with the system package manager and non-interactive build scripts.
@madaidan I re-pasted a big part of your reply from this thread because I think it is more informative and covers the degree of uncertainty in making a choice. No need to “dumb it down”.