Linux capability bounding sets are not as secure as originally intended, particularly for disabling the loading of kernel modules, as suggested in the documentation for the 'lcap' package.
This means local users might be able to load kernel modules when they shouldn't.
Background:
Linux kernels include a system setting in /proc called the "capability bounding set" that allows administrators to set which POSIX-ish capabilities should be denied all processes on the system. That is, if you disable a capability in /proc/sys/kernel/cap-bound, no process on the system can possess this capability, and no process except init may re-enable the capability in /proc/sys/kernel/cap-bound. (No existing init supports this feature AFAIK, so the capability bounding set is effectively irreversible.)
However, the capability bounding set is useless unless you disable /dev/mem, because /proc/sys/kernel/cap-bound maps directly to the cap_bset variable in kernel memory. With a quick poke (remember peek and poke from the days of BASIC on C64s and IBM PCs?) into /dev/mem, you can reset the cap_bset variable, re-enabling any or all capabilities, despite the intended one-way-ness of the capability bounding set. To get the address for cap_bset, just:
$ grep cap_bset System.map
c01d46b0 D cap_bset
Strip off the leading 'c' (since the kernel segment maps to 0xc0000000 on x86s) and you get the raw physical memory address (i.e., offset into /dev/mem) to write to. On an x86, it's a 32-bit, little-endian integer. Write 0xffffffff to it to re-enable all capabilities. (This does not give processes these capabilities; it just prevents the kernel from universally denying them as intended.)
To make capability bounding sets at all useful, you have to disable CAP_SYS_RAWIO, which governs access to /dev/mem. Be advised that doing so will break X and any other user-space program that needs raw access to memory or I/O ports.
Even if you compile a kernel with module loading completely disabled, a clever attacker could still load custom, module-like code into the kernel using /dev/mem. It's trickier than changing cap-bound, but it's still feasible, because page tables and syscall tables are similarly exposed through /dev/mem.
Possible Fix:
If you disable anything in the capability bounding set, you must also disable CAP_SYS_RAWIO and CAP_SYS_MODULE.
Upgrade:
These issues have been address a long time ago with LIDS (www.lids.org). There, not init, but a special program called lidsadm is the control center of the capabilities. It has clear documentation on why you must restrict certain capabilities, and even has the option to compile a hardcoded list of processes (such as X :) that can access /dev/mem despite the capability setting.
