Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Distros need modules, but servers seldom do.
First version of kmod released
Posted Dec 16, 2011 0:58 UTC (Fri) by linusw (subscriber, #40300)
Posted Dec 16, 2011 1:11 UTC (Fri) by dlang (✭ supporter ✭, #313)
however some distros are making this harder to do (thus the comments from some kernel devs about particular distros being very bad for kernel development because they make it hard to just use a plain kernel)
Posted Dec 16, 2011 3:20 UTC (Fri) by gsbarbieri (subscriber, #10537)
Then completely disabling module support is bad, in this case you still have udev looking for modalias and trying to resolve it. If you have it builtin or no drivers it may evaluate to empty list, currently there is no way to know it and udev worker process execute "modprobe -b ALIAS"... It will in turn execute fork, exec, linker, load of multiple index files, lookup and then exit.
With libkmod udev will be able to load the index once and do in-process resolution of alias before doing any action.
Posted Dec 16, 2011 4:09 UTC (Fri) by nybble41 (subscriber, #55106)
Posted Dec 16, 2011 4:59 UTC (Fri) by dlang (✭ supporter ✭, #313)
this didn't use to be the case.
But again, I was saying that servers seldom need modules, how frequently are you plugging random USB devices into servers?
I have been running with module support completely disabled on my servers for many years. I haven't run in to any problems with it.
Posted Dec 16, 2011 5:43 UTC (Fri) by mjg59 (subscriber, #23239)
Posted Dec 16, 2011 4:48 UTC (Fri) by josh (subscriber, #17465)
On your individual system, you could certainly build in the drivers needed to mount your root filesystem, though you'll probably still want modules for the myriad USB devices you might choose to plug in. However, you'll need an initramfs if you want any of the following:
- Root filesystem mounted by filesystem UUID or label rather than hardcoded partition name.
- Root filesystem using LVM, RAID, encryption, or any combination thereof.
- Root filesystem on a network filesystem other than NFS.
Posted Dec 16, 2011 6:00 UTC (Fri) by rvfh (subscriber, #31018)
Coming back to libkmod, I think this is long overdue and it's good to see this happening.
Posted Dec 16, 2011 17:21 UTC (Fri) by iabervon (subscriber, #722)
Posted Dec 16, 2011 17:28 UTC (Fri) by dlang (✭ supporter ✭, #313)
Posted Dec 16, 2011 18:56 UTC (Fri) by iabervon (subscriber, #722)
Posted Dec 17, 2011 22:44 UTC (Sat) by nix (subscriber, #2304)
Posted Dec 18, 2011 1:05 UTC (Sun) by HelloWorld (subscriber, #56129)
kernel modules are a convenience
Posted Dec 18, 2011 10:30 UTC (Sun) by tialaramex (subscriber, #21167)
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 (subscriber, #21283)
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).
Posted Dec 18, 2011 18:45 UTC (Sun) by PaXTeam (subscriber, #24616)
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 (✭ supporter ✭, #313)
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)
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)
Posted Dec 28, 2011 20:56 UTC (Wed) by robbe (subscriber, #16131)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds