Date: Fri, 24 Mar 2000 19:57:44 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ohoyer@fbwi.fh-wilhelmshaven.de (Olaf Hoyer) Cc: advocacy@FreeBSD.ORG Subject: Re: New article Message-ID: <200003241957.MAA08200@usr09.primenet.com> In-Reply-To: <4.1.20000324022914.00cbed30@mail.rz.fh-wilhelmshaven.de> from "Olaf Hoyer" at Mar 24, 2000 02:33:30 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> Question: Is a loadable kernel module not a potential security risk? About as much security risk as someone replacing a monolithic kernel file on you and rebooting. You have to be root do do a replacement of the kernel, you have to be root to replace a module file; you have to be root or have physical access to reboot, you have to be root in order to load a kernel module. The one difference is that with physical access, you can force a reboot to use your new kernel; but you could also stick in a CDROM or a floppy with your kernel, too, if you had physical acccess, and you wouldn't even need root to do that. Without physical access, if you have sufficient priviledge to replace the kernel or a module, then you can do a rebbot anyway. > I mean, if some module (which runs on a deeper, priviliged mode) has some > malicous code in it, or simply is buggy, and is loaded during runtime, it > could cause a box to simply crash. If the kernel is simply buggy, the system will crash. Kernel modules are the same thing as any kernel code. You can think of loading a kernel module as a form of kernel paging. > Imagine some attacker exchanging some kernel module against own code, and > causing that module to be loaded (say, some driver for access to certain > filesystems, or zip drive etc...), or waiting for the module to be loaded > (say, for regular, scheduled activities like backups or batch jobs or so) The module can't be installed for this kind of attack, without the same priviledges you'd need to attack the system by replacing the kernel itself. > Wouldn't it be safer, from a technical point of view, to allow as less > than possible kernel modules, thus enhancing stability and uptime? Yes. This has to do with how demand-loading is handled. Right now, demand loading is handled by utilities that operate against the code which has been loaded, or special purpose loader code that only does a load (like the Linux ABI module is laoded). You would gain some additional security by creating a file that contained a list of permissible modules, their paths, and the reference, in the kernel, which would cause them to load. This would require kernel level file I/O, which has stubbornly remained unstandardized, despite well designed examples like the AIX kernel thread file I/O services. It would also require, at least for devices, a devfs (and/or a major/minor mapping to a module name, and the creation of a device node that will trap and track open and closes). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003241957.MAA08200>