linux-kernel - [PATCH 03/13] Implement CAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230710102319.19716-4-greg@enjellic.com>
Date:   Mon, 10 Jul 2023 05:23:09 -0500
From:   "Dr. Greg" <greg@...ellic.com>
To:     linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, corbet@....net
Subject: [PATCH 03/13] Implement CAP_TRUST capability.

TSEM was designed to support a Trust Orchestration System (TOS)
security architecture.  A TOS based system uses the concept of a
minimum Trusted Computing Base of utilities, referred to as trust
orchestrators, that maintain workloads in a trusted execution
state.  The trust orchestrators are thus, from a security
perspective, the most security privileged processes running on
the platform.

The CAP_ML (machine modeling) capability is defined as a
capability that allows a process to alter the modeling and hence
the trust status of the platform.  In a fully orchestrated system
only the trust orchestrator carry this capability bit and then
drop the capability for the execution of the workload.  This is
designed to prevent a security vulnerability in workloads to be
leveraged to create an entity that could conduct adversarial
modifications to the trust status of the platform.

With the introduction of TSEM there are three generic mechanisms
for implementing security contols, each with its own capability
bit for management, ie:

DAC - CAP_DAC_ADMIN

MAC - CAP_MAC_ADMIN

Security modeling - CAP_ML

Having a separate capability bit for security modeling allows DAC
and classic label or path based MAC systems to be implemented in
the context of a security modeling namespace.  Looking forward it
is not unreasonable to consider the implementation of a modeling
policy that would verify the status of extended attributes being
used for label based MAC controls.

Signed-off-by: Greg Wettstein <greg@...ellic.com>
---
 include/uapi/linux/capability.h     | 6 +++++-
 security/selinux/include/classmap.h | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 3d61a0ae055d..4a17c9774505 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -417,7 +417,11 @@ struct vfs_ns_cap_data {

 #define CAP_CHECKPOINT_RESTORE	40

-#define CAP_LAST_CAP         CAP_CHECKPOINT_RESTORE
+/* Allow modifications to the trust status of the system */
+
+#define CAP_ML	41
+
+#define CAP_LAST_CAP         CAP_ML

 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)

diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index a3c380775d41..f367c269bbdb 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -30,7 +30,7 @@
 		"wake_alarm", "block_suspend", "audit_read", "perfmon", "bpf", \
 		"checkpoint_restore"

-#if CAP_LAST_CAP > CAP_CHECKPOINT_RESTORE
+#if CAP_LAST_CAP > CAP_ML
 #error New capability defined, please update COMMON_CAP2_PERMS.
 #endif

-- 
2.39.1