Linux capability bounding set weakness (fwd)

[Robert Watson]

I figured I would forward it over, even though it is presumably common
knowledge that without some sort of integrity protection for the kernel
and related system files, capabilities are not good for bounding rights,
only giving them.  This type of weakness abounds due to the uid0 and
file+device situation.  On Linux, uid0 can be exploited to gain extra
capabilities by modifying on-disk libraries, boot files, devices providing
access to kernel memory, disks directly, etc.  The BSD securelevel support
goes to great lengths to limit these avenues at high securelevels
(limiting access to modules, devices, immutable files, etc), although my
opinion is that BSD securelevels are unmanageable and at best a subset of
proper integrity protection :-).

One particularly useful point is this: the stronger the restrictive
guarantees made by those of us promoting capabilities, the further we have
to fall.  :-)  This isn't to say that capabilities aren't useful, but this
certainly does seem to reflect on the issues we discussed in Mountain View
a couple of weeks ago relating to mixing uid0 and capability-based rights.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

---------- Forwarded message ----------
Date: Mon, 26 Jun 2000 21:05:34 -0400
From: Patrick Reynolds <reynolds at CS.DUKE.EDU>
To: BUGTRAQ at SECURITYFOCUS.COM
Subject: Linux capability bounding set weakness

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

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message