Talking about security issues is fashionable these days, and most programmers are concerned about their systems’ security, so I’ll address the problem at the beginning to avoid later misunderstandings.

Security has two faces. One problem is what a user can achieve through the misuse of existing programs, or by exploiting bugs; a different issue is what kind of (mis)functionality a programmer can implement. The programmer has, obviously, much more power than a plain user. In other words, it’s more dangerous to run as root a program you got from a friend than to give him or her a root shell once in a while. Although having access to a compiler is not a security hole per se, the hole can appear when compiled code is actually executed; be careful with modules, because a kernel module can do anything. A module is much more powerful than a superuser shell, in that its privileged status is acknowledged by the CPU.

Any security check in the system is enforced by kernel code. If the kernel has security holes, then the system has holes. In the official kernel distribution, only root can load modules; the system call create_module checks the user ID of the invoking process. Thus with the official kernel, only the superuser, or an intruder who has succeeded in becoming root, can exploit the power of privileged code.

Fortunately, when writing a device driver or other module, there’s little need to be concerned about security because processes accessing the device are already constrained by more general blocking techniques. With block devices, for example, security is handled by the permissions on the filesystem node and the mount command, so usually nothing has to be checked in the actual block driver.

Be careful, however, when receiving software from third parties, especially when the kernel is concerned: since everybody has access to the source code, everybody can break and recompile things. While you can trust precompiled kernels found in your distribution, you should avoid running kernels compiled by an untrusted friend—if you wouldn’t run a precompiled binary as root, then you’d better not run a precompiled kernel. For example, a maliciously modified kernel could allow anyone to load a module, thus opening an unexpected back door via create_module.

If you are really concerned about system security in relation to modules, I’d urge you to look at how the securelevel kernel variable is used. As I write this, there is ongoing discussion in the Linux community about the prevention of module loading and unloading under the control of securelevel. It’s interesting to note that with recent kernels, support for modules can be removed at kernel compile time, thus closing any related security hole.