OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Linux capability bounding set weakness
From: Matthew Kirkwood (weejockFERRET.LMH.OX.AC.UK)
Date: Tue Jun 27 2000 - 17:07:52 CDT

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.)