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: