Bugtraq mailing list archives
Linux capability bounding set weakness
From: reynolds () CS DUKE EDU (Patrick Reynolds)
Date: Mon, 26 Jun 2000 21:05:34 -0400
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 and in two back issues of Linux Weekly News. Background: recent 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, reenabling 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. As an aside, more fun with module security... 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. Exploit: read open(2) and mmap(2) and write it yourself. Fix: if you disable anything in the capability bounding set, you must also disable CAP_SYS_RAWIO and CAP_SYS_MODULE. --Patrick
Current thread:
- Re: ftpd: the advisory version Lamagra Argamal (Jun 24)
- Re: ftpd: the advisory version Jim Knoble (Jun 26)
- Re: ftpd: the advisory version Olaf Kirch (Jun 27)
- Re: ftpd: the advisory version Mike Eldridge (Jun 29)
- Re: ftpd: the advisory version Olaf Kirch (Jun 27)
- Linux capability bounding set weakness Patrick Reynolds (Jun 26)
- Re: Linux capability bounding set weakness Paul Wouters (Jun 27)
- Re: Linux capability bounding set weakness Matthew Kirkwood (Jun 27)
- Improved ARP sniffer Paul Starzetz (Jun 27)
- [suse-security-announce] SuSE Security Announcement: kernel-2.2.x (fwd) Daniel T. Chen (Jun 27)
- <Possible follow-ups>
- Re: ftpd: the advisory version Steven M. Bellovin (Jun 26)
- Re: ftpd: the advisory version Dan Harkless (Jun 27)
- Re: ftpd: the advisory version Teodor Cimpoesu (Jun 28)
- Re: ftpd: the advisory version Sebastian (Jun 28)
- Re: ftpd: the advisory version Kasatenko Ivan Alex. (Jun 29)
- Re: ftpd: the advisory version Barney Wolff (Jun 29)
- Re: ftpd: the advisory version Jim Knoble (Jun 26)