| |||||||||||||
urghurghPosted Mar 18, 2004 3:27 UTC (Thu) by mattdm (subscriber, #18)Parent article: A new Adore root kit I'm no kernel hacker, but it seems like something like this would be a good thing: In /etc somewhere, have a file containing checksums of modules which are allowed to be loaded in the kernel. Then, some kernel mechanism to read this file _once_ -- and once read, make it impossible to add to the list without a reboot. This would be far from perfect protection, but seems like it'd provide another layer of protection -- the attacker would have to reboot the system, which is at least noticable. It'd also be kind of a pain for third-party drivers, but....
(Log in to post comments)
Allowed modules list Posted Mar 18, 2004 3:32 UTC (Thu) by corbet (editor, #1) [Link] If you're really concerned, a better solution is to link everything you need into your kernel and disallow modules altogether. A weaker alternative is to load your modules at boot time, then disable module loading via the capability bounding set.In either case, however, you must contend with the fact that it is still possible to patch code into the kernel without loading a module via /dev/mem.
Allowed modules list Posted Mar 18, 2004 4:12 UTC (Thu) by mattdm (subscriber, #18) [Link] Hmmm, yeah, I vaguely remember reading about that.So, is some sort of hardware-based code signing really the only thing that can be done? Other than "don't let bad people get root", of course.
Allowed modules list Posted Mar 18, 2004 4:19 UTC (Thu) by mebrown (subscriber, #7960) [Link] Compile out support for /dev/mem?or, Arjan has patches for 2.6 in the RH kernel that allow access through /dev/mem to only the first 1MB of memory (for tools that look at BIOS info, eg SMBIOS), and non-RAM memory (X drives PCI cards using IO through /dev/mem).
Allowed modules list Posted Mar 18, 2004 7:01 UTC (Thu) by sweikart (guest, #4276) [Link] >In either case, however, you must contend with the fact that it is still >possible to patch code into the kernel without loading a module via /dev/mem. To block access through /dev/mem, just drop the sys_rawio capability. [You might even be able to drop sys_rawio after starting X; I've only dropped it on servers.] Some good references are: http://lwn.net/1999/1202/kernel.php3 http://lwn.net/2000/0629/backpage.php3 # Subject: disabling module loading
Allowed modules list Posted Mar 18, 2004 9:22 UTC (Thu) by eru (subscriber, #2753) [Link] If you're really concerned, a better solution is to link everything you need into your kernel and disallow modules altogether.But I recall that some time ago LWN (or possibly some other Linux web page, not sure) reported discussions among kernel developers about deprecating the making of statical kernels altogether. Did that already happen with 2.6? Is it likely to happen? Anyway, this solution is not quite feasible for most ordinary users: configuring the kernel with its hundreds of options is tedious, and I have found it can be difficult to decide what drivers or features can be disabled safely. The result is also less flexible when new hardware is installed. So I do not think the statical kernel a very practical solution for most users. Other alternatives are needed for securing against rootkit modules..
Allowed modules list Posted Mar 18, 2004 11:31 UTC (Thu) by nix (subscriber, #2304) [Link] Anyway, this solution is not quite feasible for most ordinary users: configuring the kernel with its hundreds of options is tedious, and I have found it can be difficult to decide what drivers or features can be disabled safely. The result is also less flexible when new hardware is installed. So I do not think the statical kernel a very practical solution for most users.This may well be true for general-purpose systems (although I haven't found it so), but firewalls, at least, can run with module support removed (no matter what their hardware: if necessary, run the firewall as a UML instance with no module support. UML's not *quite* secure, and won't be until lcall syscalls can be virtualized, but it's damned close.)
What protection does module versioning provide? Posted Mar 18, 2004 13:21 UTC (Thu) by rankincj (subscriber, #4865) [Link] How would the attacker arrange for the module to get silently reloaded after a reboot? Wouldn't they need to hook something into your init scripts somehow? And what happens when you upgrade or recompile your kernel? You may be able to force an insmod of Adore's modules, but there's no guarantee that they would still work.
Allowed modules list Posted Mar 18, 2004 22:24 UTC (Thu) by LogicG8 (guest, #11076) [Link] A list of allowed modules won't help much ifa user has root privileges. With any *nix once root is obtained the system is completely comprimised. For those interested in patching the kernel w/o LKM
Allowed modules list Posted Mar 19, 2004 1:40 UTC (Fri) by giraffedata (subscriber, #1954) [Link] A list of allowed modules won't help much if a user has root privileges.It would if you implemented the rest of the proposal, which was to make the kernel not allow updating of this list by anyone. It was, of course, left vague how you might design something like that. With any *nix once root is obtained the system is completely compromised. That's very on-point. It's why the best reaction to this type of threat is to make it harder to "obtain root," by making "root" far less pervasive in a system. Linux took steps toward this long ago by replacing the traditional Unix concept of superuser/not superuser with a set of fine grained capabilities. As has been pointed out, if you had every one except CAP_SYS_MODULE, you would not be able to install Adore. And if only processes that needed CAP_SYS_MODULE had CAP_SYS_MODULE, it would be next to impossible for the cracker to find one that he can trick into loading Adore. It isn't customary on Linux systems to manipulate individual capabilities, but it should be. For that matter, there's still a whole lot of code running with full capabilities that doesn't need any of them at all. I.e. it should "drop root." One thing I don't know the status of: capabilities assigned to executables. Last I saw, if you need a privileged program, you have to make it setuid/owner 0 and then whoever executes it gets ALL capabilities. We need to do better than that.
LIDS, SELinux, etc Posted Mar 19, 2004 1:51 UTC (Fri) by AnswerGuy (guest, #1256) [Link] It's not quite true that root-compromised systems *have* to be inherently, persistenly compromised. It's CLOSE to true; but some features in LIDS and SELinux could protect a well configured system even from a rogue root process. These patches work by limiting root's power and imposing additional authentication/authorization measures for some operations. JimD
Allowed modules list Posted Oct 25, 2004 0:44 UTC (Mon) by jcm (subscriber, #18262) [Link] Hi all,
It's worth noting that the issue of signed modules has recently cropped up in a debate on lkml. It looks as though something will eventually go mainstream - but what form it'll take is still subject to list wrangling.
Cheers,
Jon.
Signed modules, "Sealed" mode etc Posted Mar 19, 2004 1:46 UTC (Fri) by AnswerGuy (guest, #1256) [Link] There are various patches such as LIDS and (DSIGN?) that limit allowed modules or "seal" the kernel after boot and refuse to let modules load or do digital signature checks before linking into loadable modules. (The capability bounding set is a coarse grained measure in this direction --- but it's the only one in a stock kernel). There are many countermeasures to each of the steps that any
urgh Posted Oct 4, 2004 13:25 UTC (Mon) by arafel (subscriber, #18557) [Link] Give someone sufficient privileges to load a kernel module, and I can guarantee that, if they really want, it will be loaded one way or the other. Bear in mind that any code which you can write to check for an 'allowed' module list can simply be changed to always return 'yes, that module is okay'.
|
|||||||||||||