First version of kmod released

Posted Dec 16, 2011 18:56 UTC (Fri) by iabervon (subscriber, #722)
In reply to: First version of kmod released by dlang
Parent article: First version of kmod released

On my server, I've still occasionally had the experience of wanting to add a device I didn't originally anticipate needing when I built my kernel. It happens a lot less, and the steady state is 0 modules loaded (and 0 built), but I find it comforting to be able to build and load a module if I need it without rebooting.

First version of kmod released

Posted Dec 17, 2011 22:44 UTC (Sat) by nix (subscriber, #2304) [Link] (8 responses)

Quite. It's firewalls and other directly-hostile-Internet-exposed systems on which I enforce a CONFIG_MODULES=n rule.

First version of kmod released

Posted Dec 18, 2011 1:05 UTC (Sun) by HelloWorld (guest, #56129) [Link] (6 responses)

The point being? If somebody breaks into your box and gains enough privileges to load a kernel module, he'll also be able to replace the kernel.

kernel modules are a convenience

Posted Dec 18, 2011 10:30 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (4 responses)

In fact the somebody can inject a kernel module anyway. The kernel's module enable/ disable is a convenience, not a necessity. Way back when this stuff first happened, and we had the first generation of people saying they're going to disable modules for security reasons, grey hats built POC module injectors which work whether or not modules are "enabled" to show how ludicrous this idea is.

IF you set up the system so that root has far less than traditional privileges and IF you've identified and correctly repaired every hole in the resulting fence between system privileges exercised by the kernel and the privileges of the root user, then maybe you buy some small amount of additional security through disabling kernel modules. But for most people it's equivalent to using a toddler gate as additional security. You may trip up a few babysitters but you won't hamper a burglar.

kernel modules are a convenience

Posted Dec 18, 2011 15:53 UTC (Sun) by ranmachan (guest, #21283) [Link] (1 responses)

<matrix style>
How do you inject a kernel module...
...if you don't have access to kernel memory?
</matrix style>

CONFIG_STRICT_DEVMEM=y

Though you still can just replace the kernel image and reboot into that.
However if you run on e.g. Xen you can prevent that as well, leaving only comparatively more easy to detect user-mode root kits (ignoring possible supervisor bugs or an insecure dom0).

kernel modules are a convenience

Posted Dec 18, 2011 18:45 UTC (Sun) by PaXTeam (guest, #24616) [Link]

> CONFIG_STRICT_DEVMEM=y

you'd think it does what you think it does but it doesn't... which pill did you take? ;)

kernel modules are a convenience

Posted Dec 18, 2011 16:53 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

I think that you underestimate the number of script kiddies out there who don't really know what they are doing.

Along similar lines, an attacker can load any software on the system that they want, so the best practice of not installing anything on servers that you don't need (and especially compilers, sniffers, etc) won't stop a determined attacker.

but in both cases (module loading and installed software), if you can make it harder for an attacker to do stuff on your systems, any attacker who is not out to get you specifically, but is instead just out to get whoever they can will find that their standard tools don't work and are likely to go elsewhere rather than figuring out what they would need to do.

worms and other automated attacks also are unlikely to be able to deal with anything that's non-standard, so anything that you can do to make such tools not work out of the box can be a big win.

Again, if the bad guy is one of the elite hackers and is out to get you specifically (Advanced Persistent Threat is the term used for this nowdays), none of this will help much (although it _may_ slow them down just enough for your IDS to notice), but against the other attacks this helps in the "I don't have to outrun the bear, I just have to outrun you" type of way.

kernel modules are a convenience

Posted Dec 19, 2011 1:57 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I would argue that if you are falling to worms or automated attacks that you probably aren't doing anything for security or patching as most automated attacks use low-value, quickly-patched vulnerabilities to spread. IMHO if you have all the basics covered, mangling your OS install isn't going to buy you a whole heck of a lot except for management headaches and you will end up installing those tools (sniffers, etc.) anyway because they are useful.

I would argue that for an APT, no matter how hard you work it won't be enough to keep them out so a strong audit capability to detect unusual activity quickly so you can shut it down and clean it up is a better use of time and resources. Much like how the credit card industry focuses on fraud detection, after transactions have cleared, rather than prevention. Logging and reviewing all sudo logs and other root activity is simple and low overhead and pretty effective.

First version of kmod released

Posted Dec 18, 2011 17:12 UTC (Sun) by nix (subscriber, #2304) [Link]

Yeah, but there's no point in making attackers' jobs *easy*.

First version of kmod released

Posted Dec 28, 2011 20:56 UTC (Wed) by robbe (guest, #16131) [Link]

Hmm, on netfilter based firewalls, I like the ability to have some seldomly used filter modules lying around, and being able to load them "on demand". I almost never do this, so it is more of a (in?)security blanket.

If we tread into proprietary waters, most Check Point firewalls are based on Linux and load part of their code as a monstrously big kernel module -- making this feature mandatory there.