Caring about protecting the kernel from UID 0 was previously relatively
uninteresting, since an attacker could simply modify the kernel, a module
or an earlier part of the boot chain in order to insert new code. However,
there are now a range of widely-deployed mechanisms for ensuring the
authenticity of the early boot process and kernel. The addition of module
signing makes most of these attacks infeasible.
This means we can return our focus to the kernel. There's currently a number
of kernel interfaces that permit privileged userspace to modify the running
kernel. These are currently protected by CAP_SYS_RAWIO, but unfortunately
the semantics of this capability are poorly defined and it now covers a large
superset of the desired behaviour.
This patch introduces CAP_COMPROMISE_KERNEL. Holding this capability
indicates that a process is empowered to perform tasks that may result in
modification of the running kernel. While aimed at handling the specific
use-case of Secure Boot, it is generalisable to any other environment where
permitting userspace to modify the kernel is undesirable.
Signed-off-by: Matthew Garrett <matthew.garrett@xxxxxxxxxx>
---
include/uapi/linux/capability.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index ba478fa..7109e650 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -343,7 +343,11 @@ struct vfs_cap_data {
#define CAP_BLOCK_SUSPEND 36
-#define CAP_LAST_CAP CAP_BLOCK_SUSPEND
+/* Allow things that trivially permit root to modify the running kernel */
+
+#define CAP_COMPROMISE_KERNEL 37
+
+#define CAP_LAST_CAP CAP_COMPROMISE_KERNEL
#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
