Bugtraq mailing list archives
Re: Linux capability bounding set weakness
From: weejock () FERRET LMH OX AC UK (Matthew Kirkwood)
Date: Tue, 27 Jun 2000 23:07:52 +0100
Hi, As the original implementor, I felt that I should respond. I'm not quite sure of the point you're trying to make here, though. I do think that the facts that you point out should be better documented, though part of me thinks that it should be sufficiently self-evident not to need that.
To make capability bounding sets at all useful, you have to disable CAP_SYS_RAWIO, which governs access to /dev/mem.
I dispute this. To make them at all useful, you have to disable _or closely, (ideally provably) protect_ CAP_SYS_RAWIO. Obviously a setuid-root X server doesn't help here, but some small necessary evils[0] which aren't setuid (or {fs,elf}cap'ped) don't increase practical risk, as far as I can see. As it happens, before 2.2.7 or thereabouts, CAP_SYS_RAWIO was not required open /dev/mem, /dev/kmem, /dev/port or /proc/kcore. I am actually not at all confident that I didn't miss a other places either. There are a lot of privileged ioctls which allow setting hardware options (including I/O ports) which haven't been fixed. I suspect that the worst of them would offer no more than a DoS, but you never know which might offer worse.. I did, at one stage, have a patch which changed a lot of these, but never got around to submitting it for an official kernel. Thinking about it once more, it should probably demand both CAP_SYS_ADMIN and CAP_SYS_RAWIO for most of these things. Anyway, it's at http://ferret.lmh.ox.ac.uk/~weejock/cap-rawio-fixes.diff
Be advised that doing so will break X and any other user-space program that needs raw access to memory or I/O ports.
Such programs are inherently broken from a strict security POV. Again, this is perhaps underdocumented,
Fix: if you disable anything in the capability bounding set, you must also disable CAP_SYS_RAWIO and CAP_SYS_MODULE.
Strongly disagree. CAP_SYS_RAWIO and CAP_SYS_MODULE. (and quite possibly others) must be protected at least as much as /proc/sys/kernel/cap-bound. Fix: document this adequately. Matthew. [0] kbdrate is the only one which springs to mind, and it's not a particularly instructive example. (Though Red Hat 6.x's "consolehelper" does allow mortals to run it.)
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 Sebastian (Jun 29)
- (forw) Re: Netscape ftp Server (fwd) Elias Levy (Jun 29)
- Re: ftpd: the advisory version Jim Knoble (Jun 26)