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?