First version of kmod released
First version of kmod released
Posted Dec 17, 2011 22:44 UTC (Sat) by nix (subscriber, #2304)In reply to: First version of kmod released by iabervon
Parent article: First version of kmod released
Posted Dec 18, 2011 1:05 UTC (Sun)
by HelloWorld (guest, #56129)
[Link] (6 responses)
Posted Dec 18, 2011 10:30 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
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.
Posted Dec 18, 2011 15:53 UTC (Sun)
by ranmachan (guest, #21283)
[Link] (1 responses)
CONFIG_STRICT_DEVMEM=y
Though you still can just replace the kernel image and reboot into that.
Posted Dec 18, 2011 18:45 UTC (Sun)
by PaXTeam (guest, #24616)
[Link]
you'd think it does what you think it does but it doesn't... which pill did you take? ;)
Posted Dec 18, 2011 16:53 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
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.
Posted Dec 19, 2011 1:57 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
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.
Posted Dec 18, 2011 17:12 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Dec 28, 2011 20:56 UTC (Wed)
by robbe (guest, #16131)
[Link]
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.
First version of kmod released
kernel modules are a convenience
kernel modules are a convenience
How do you inject a kernel module...
...if you don't have access to kernel memory?
</matrix style>
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
kernel modules are a convenience
kernel modules are a convenience
First version of kmod released
First version of kmod released