Add SetCapabilities for setting capabilities to an exact set.

sandbox/linux/system_headers/capability.h

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef SANDBOX_LINUX_SYSTEM_HEADERS_LINUX_CAPABILITY_H_
+#define SANDBOX_LINUX_SYSTEM_HEADERS_LINUX_CAPABILITY_H_
+
+#include <stdint.h>
+
+// The following macros are taken from linux/capability.h.
+// We only support capability version 3, which was introduced in Linux 2.6.26.
+#ifndef _LINUX_CAPABILITY_VERSION_3
+#define _LINUX_CAPABILITY_VERSION_3 0x20080522
+#endif
+#ifndef _LINUX_CAPABILITY_U32S_3
+#define _LINUX_CAPABILITY_U32S_3 2

[jln (very slow on Chromium), 2015/03/12 19:24:15]

Did you figure out what the comment

"Backwardly compatible definition for source code - trapped in a 32-bit world.
If you find you need this, please consider using libcap to untrap yourself..."
means?

[rickyz (no longer on Chrome), 2015/03/12 23:36:02]

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ca0...
has the hairy details.

Apparently, when they made the change for the syscall to take an array of two
struct cap_data instead of one, they just bumped the macros with the default
values. I guess some people didn't use an array with _LINUX_CAPABILITY_U32S
elements for cap_data, which caused the syscall to write past the end of
cap-data. What a sad API :-(

+#endif
+#ifndef CAP_TO_INDEX
+#define CAP_TO_INDEX(x) ((x) >> 5)  // 1 << 5 == bits in __u32
+#endif
+#ifndef CAP_TO_MASK
+#define CAP_TO_MASK(x) (1 << ((x) & 31))  // mask for indexed __u32
+#endif
+#ifndef CAP_SYS_ADMIN
+#define CAP_SYS_ADMIN 21
+#endif
+#ifndef CAP_SYS_CHROOT
+#define CAP_SYS_CHROOT 18
+#endif
+#ifndef CAP_LAST_CAP
+#define CAP_LAST_CAP 36
+#endif
+
+struct cap_hdr {
+  cap_hdr() : version(0), pid(0) {}
+  uint32_t version;
+  int pid;
+};
+
+struct cap_data {

[jln (very slow on Chromium), 2015/03/12 19:24:15]

I'm pretty sure this should be fine, but I'm slightly worried about not having
"exactly" what's in the kernel.

I suspect / hope that C++ still guarantees that these struct will be represented
the same in memory?

[mdempsky, 2015/03/12 20:43:42]

Another worry is if we write code assuming that cap_data will implicitly
zero-initialize, but then we switch to using the kernel's headers and get
cap_hdr/cap_data that won't.

[rickyz (no longer on Chrome), 2015/03/12 23:36:02]

That's a good point - switched to explicitly zeroing.

+  cap_data() : effective(0), permitted(0), inheritable(0) {}
+  uint32_t effective;
+  uint32_t permitted;
+  uint32_t inheritable;
+};
+
+#endif  // SANDBOX_LINUX_SYSTEM_HEADERS_LINUX_CAPABILITY_H_