LKRG Lockdown

[kcdev809]

Description

This adds some code to bump the module refcount to prevent unloading LKRG. Only makes sense with kernel lockdown enabled and a kernel built with 'CONFIG_MODULE_FORCE_UNLOAD=n' .

How Has This Been Tested?

Module was compiled with changes and behaved as expected during testing.

[solardiz]

Thank you for the suggestion/contribution!

This adds some code to bump the module refcount to prevent unloading LKRG. Only makes sense with kernel lockdown enabled and a kernel built with 'CONFIG_MODULE_FORCE_UNLOAD=n' .

I think this is too much of a special case. If we add unload protection, it should be more general. Also, we need to maintain a consistent security model against a relevant threat model. There's little point in disallowing LKRG unload when we don't also disallow reconfiguration via sysctl that would effectively disable LKRG (while keeping it loaded). Rather, it'd make more sense to have a combined "no unload or configuration weakening" setting that would work for all installs.

So as much as we'd have liked to gain you as a contributor, I think we shouldn't merge this specific change now.

@Adam-pi3 @kerneltoast What do you think?

There are also some minor issues I see in the code, such as wrong indentation. But no point fixing this if we aren't going to merge this in principle.

[kerneltoast]

I don't think this makes much sense given that lockdown only has value when used in conjunction with secure boot. That means you'd need to get lkrg.ko signed by a secure boot CA or use your own secure boot key.

And per the spirit of lockdown, the sysctl knobs would indeed need to be locked down when the lockdown LSM is active. I don't think this effort is worth it right now.

[kcdev809]

Yes, this needs to be combined with further lockdown of certain config values.

[solardiz]

I dislike tying this functionality to lockdown in any way at all. I think we don't have to.

[kcdev809]

Kernel lockdown is a core part of kernel-mode security. Perhaps tying this could be set by a build-time flag?

[solardiz]

I really would rather keep our lockdown feature separate from kernel lockdown, working independently of whether kernel lockdown is supported/enabled. I don't want to clutter the project (and documentation!) with more build-time flags.

[solardiz]

Also, there was the idea of password-protected (we'd keep a hash) unload/reconfiguration. We'll probably want that eventually.

[kcdev809]

Also, there was the idea of password-protected (we'd keep a hash) unload/reconfiguration. We'll probably want that eventually.

That would be a good idea, gives users some more flexibility (fail safe in case of errors).
But on the other topic, I would consider implementing more build-time flags to give flexibility to distro package maintainers.
Tying LKRG lockdown to kernel lockdown may be desired if a distro is meant to have a secure & easy OOBE (especially since nowadays all the big distros have their own code signing CA for module signing, Secure Boot / Microsoft-Signed Shim, IMA).

[Adam-pi3]

@Adam-pi3 @kerneltoast What do you think?

It may have sense if we improve self-defense, hiding and lock sysctl as was mentioned by @solardiz and @kerneltoast. I think our old idea of passowrd protected unload (and sysctl) would likely be a good option to explore

[kcdev809]

I've changed my code to add a separate LKRG lockdown mechanism (optionally auto-invoked by kernel lockdown). Will be easier now to add sysctl protection.

EDIT: not yet added possibility of LKRG_LOCKED_DOWN=0 & LKRG_LOCKDOWN_BY_KERNEL=0 but lock down LKRG via command line