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)
