< Features
modprobe Whitelist
Summary
Add a whitelist of allowed modules and commands to modprobe, to allow the system administrator to limit the amount of (potentially vulnerable) code that can run in the kernel.
Owner
- Name: Miloslav Trmac
- Email: <mitr@redhat.com>
Current status
- Targeted release: Fedora 13
- Last updated: 2010-01-21
- Percentage of completion: 10%
Detailed Description
The kernel, and various user-space applications, can automatically load kernel modules necessary to handle certain actions (e.g. hardware is plugged in, application uses a network protocol or an iptables module). This may allow even unprivileged users to cause loading kernel modules, and the kernel code may be vulnerable. This feature allows system administrators in high-security situations to limit the modules loaded by modprobe to a specific list of modules configured by the administrator, making it impossible for unprivileged users to exploit vulnerabilities in modules that are not ordinarily used by e.g. attaching hardware.
modprobe can also run specified commands instead of loading a module (using the "install" configuration directive); this is restricted using the same whitelist as well.
To help system administrators compile the whitelist, additional functionality is added to modprobe: it will be possible to log all information (as if using "modprobe -v") to a specified file, including modprobe actions run in the dracut initrd. A script will be provided that compiles a proposed whitelist from the logged data.
Benefit to Fedora
If desired and configured by the system administrator, a significant reduction of the kernel-space attack surface, avoiding risk of vulnerabilities in rarely-used kernel-mode code.
A sample desktop Fedora 12 system currently has 79 modules loaded, out of 1964 available modules (4%). When counting code size, and the main kernel file (/boot/vmlinuz*) is included, the sample desktop system runs 8.36 MB of kernel-space code, out of 34.66 MB available (24%).
Scope
New features in modprobe and a very small addition to dracut (to copy the log data from the initrd to the root filesystem).
How To Test
No special hardware needed.
- Configure modprobe to log its actions, reboot the system and use it as usual.
- Disable the logging, generate a whitelist using a provided script.
- Reboot again, verify system works correctly. Verify other modules can't be loaded.
- Regenerate the initrd (to embed the whitelist into the initrd), reboot, verify the system still works correctly.
- Using dracut's debugging facilities, verify the whitelist is enforced even in the initrd.
User Experience
No impact by default. System administrators who want to build a whitelist can do so, following documentation that will be provided.
Dependencies
Upstream acceptance in module-init-tools.
Contingency Plan
None necessary.
Documentation
To be written.
Release Notes
To be written
Comments and Discussion