tree ddfa19bbe14403ce869272bf8194e2f125470a52
parent d96baf4ebf0a35aca42c38f25c1b20424e273e5d
author Mike Frysinger <vapier@chromium.org> 1368134348 -0400
committer ChromeBot <chrome-bot@google.com> 1368140789 -0700

capabilities: extract the max cap from the runtime system

The cap_valid() macro checks against a max define hardcoded at build time
from the kernel headers.  The runtime kernel might have a different max
value which means this code doesn't work exactly as we want.

For example, if you build against linux-3.8 headers but boot with a 3.4
kernel, the kernel headers know about 36 caps while the runtime kernel
only knows about 35.  When this minijail code tries to drop capset 36, it
dies because the kernel returns EINVAL.

Conversely, if you were to build against linux-3.4 headers but boot a 3.8
kernel, minijail would know to drop caps up through 35, but that 36 would
remain in place.

Typically these scenarios don't happen, but as people develop/test things,
it's not unreasonable to try these out (think testing newer kernel headers
or booting kernel next).  As such, suck up the max value at runtime via
/proc and use that instead.

BUG=None
TEST=built against linux-3.8 headers and booted a linux-3.4 kernel;
	minijail no longer aborts (networking works), and some logging added
	to the kernel shows it running PR_CAPBSET_DROP for [0, 35] since the
	runtime kernel max is 35 (even though the compiled headers say 36).

Change-Id: Ie9aec101263402a3e147e85caf1e8bda78008aa3
Reviewed-on: https://gerrit.chromium.org/gerrit/50702
Reviewed-by: Kees Cook <keescook@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>