On Mon, Dec 26, 2011 at 04:42:45PM +0600, Andrey Rahmatullin wrote: > On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote: > > > > All admins I know have at least some servers with custom kernels (in the > > > > past it was said, to build your firewall/server kernels without module > > > > support, so that no rootkit module could be loaded). > > > > > > No longer needed. See /proc/sys/kernel/modules_disabled. > > > > That's not equivalent - an attacker that can load modules can also > > remove the init script that sets this variable to 1 and reboot the > > machine. > Why can't the same attacker replace the kernel? On Mon, Dec 26, 2011 at 12:01:43PM +0100, Philipp Kern wrote: > > For proper safeguarding you still want no module support in the kernel > > at all. > > Sorry, but what kind of argumentation is that? If the admin doesn't notice > reboots and/or file tampering, I could just replace the kernel with my modified > one and reboot. Now of course you could increase your paranoia and boot the > kernel from an immutable disc. But then I'd just load all relevant modules in > the initramfs and set modules_disabled there instead of doing custom built > kernels just to get rid of modules. For both of you: for virtualised environments where the kernel is loaded from the hypervisor. Yes, doing the initrd from the hypervisor helps too, but the problem with that setting is that it defaults to 0 and has to be switched to 1. Whereas a kernel with no module support defaults to 0. regards, iustin
Attachment:
signature.asc
Description: Digital signature