5233445 2000-06-27 22:11 /60 rader/ Postmaster
Mottagare: Bugtraq (import) <11453>
Ärende: Linux capability bounding set weakness
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
X-Sender: patrick@s-reynolds.cs.duke.edu
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.10.10006262044240.1191-100000@s-reynolds.cs.duke.edu>
Date: Mon, 26 Jun 2000 21:05:34 -0400
Reply-To: Patrick Reynolds <reynolds@CS.DUKE.EDU>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Patrick Reynolds <reynolds@CS.DUKE.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
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
(5233445) ------------------------------------------(Ombruten)
5236173 2000-06-28 21:50 /43 rader/ Postmaster
Mottagare: Bugtraq (import) <11474>
Ärende: Re: Linux capability bounding set weakness
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.21.0006272246120.2031-100000@duplo.xtdnet.nl>
Date: Tue, 27 Jun 2000 22:50:44 +0200
Reply-To: Paul Wouters <paul@XTDNET.NL>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Paul Wouters <paul@XTDNET.NL>
X-To: Patrick Reynolds <reynolds@CS.DUKE.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.10.10006262044240.1191-100000@s-reynolds.cs.duke.edu>
On Mon, 26 Jun 2000, Patrick Reynolds wrote:
> 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.
> Fix: if you disable anything in the capability bounding set, you must also
> disable CAP_SYS_RAWIO and CAP_SYS_MODULE.
These issues have been address a long time ago with LIDS
(www.lids.org). There, not init, but a special program called
lidsadm is the control center of the capabilities. It has clear
documentation on why you MUST restrict certain capabilities, and even
has the option to compile a hardcoded list of processes (such as X :)
that can access /dev/mem despite the capability setting.
I can recommend lids as a VERY good way to secure your system so
much, you'll find it impossible to cleanyl shutdown or reboot
altogehter :)
See http://www.ota.be/linux/workshops/20000527/ for a RealMedia
overview of LIDS that I gave a few weeks ago for the OTA.
Paul
--
Only the access to the source code of our future television sets will
guarantee the independence of content and technology.
--- www.linuxtv.org
(5236173) ------------------------------------------(Ombruten)
5236506 2000-06-29 00:43 /69 rader/ Postmaster
Mottagare: Bugtraq (import) <11491>
Ärende: Re: Linux capability bounding set weakness
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.21.0006272236380.26192-100000@ferret.lmh.ox.ac.uk>
Date: Tue, 27 Jun 2000 23:07:52 +0100
Reply-To: Matthew Kirkwood <weejock@FERRET.LMH.OX.AC.UK>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Matthew Kirkwood <weejock@FERRET.LMH.OX.AC.UK>
X-To: Patrick Reynolds <reynolds@CS.DUKE.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.10.10006262044240.1191-100000@s-reynolds.cs.duke.edu>
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.)
(5236506) ------------------------------------------