Date: Sun, 14 Jun 2020 20:21:39 +0200 From: Mikhail Morfikov <mmorfikov@...il.com> To: lkrg-users@...ts.openwall.com Subject: Re: rootkit detection On 14/06/2020 17:37, Solar Designer wrote: > > Of course, none of these rootkits tried to bypass LKRG. If they wanted > to, they could e.g. simply "rmmod p_lkrg" before loading themselves into > the kernel. (Or the attacker could do that manually.) In LKRG > development, we're currently more focused on exploits run before the > attacker got legitimate-looking privileged access to the system. We're > not as focused on rootkits, which are loaded with legitimate-looking > privileged access. Removing the LKRG module via "rmmod p_lkrg" sometimes may not be so easy. In the case of my Debian system, I have the Secure Boot mode enabled. Also since kernel 5.4 there's the kernel lockdown mechanism, and in Debian it also was extended by the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT option, which automatically sets the kernel lockdown mode when the system is booted with Secure Boot enabled. So with the kernel lockdown, you can't load modules that weren't signed by some verified keys, and loading modules like the Keysniffer would simply fail in such systems. I also removed the default EFI certs and added my own certs to the firmware in the place of the older ones to make sure that the kernel/bootloader (and anything else) can be loaded only when it was signed by me, and only me. Also even if someone doesn't use the Secure Boot/Kernel lockdown mode, there's CONFIG_MODULE_SIG_FORCE, which can prevent loading unsigned modules and stop them from doing some harm in the system, though it's not default in the distro kernels. But having either one setup would make extremely hard or impossible to load any additional unsigned modules in a working system. Even if none of the above solutions would be used, there's still the CONFIG_MODULE_UNLOAD option that can prevent the LKRG module from being unloaded, but since LKRG depends on this option (it has to be set to "yes"), it asks itself for troubles, especially on the systems where Secure Boot/Kernel lockdown isn't an option. So not forcing people to have CONFIG_MODULE_UNLOAD enabled would simply help the LKRG module (and other security modules) from being unloaded in such cheap way. Also there's, a kernel sysctl option provided by LKRG, which is lkrg.block_modules, but this is rather weak now, since it simply block loading of modules when it's set. It actually doesn't prevent the LKRG module from being unloaded. But there's also the sysctl option kernel.modules_disabled, and this one (when set) blocks loading/unloading of modules, and reboot is required to change the value of this parameter. So to prevent LKRG from being unloaded, a user can set that last option to "1", but it always has to be done in working system when it boots, so it's not as strong as CONFIG_MODULE_UNLOAD, but it's better than nothing. :) Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.