Re: [PATCH 03/13] Implement CAP_TRUST capability.

[Casey Schaufler]

On 7/10/2023 3:23 AM, Dr. Greg wrote:
> 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

There is no CAP_DAC_ADMIN. There are several capabilities related
to changing the DAC state of the system.

>
> MAC - CAP_MAC_ADMIN

Since your system implements a mandatory access control policy
you should be using CAP_MAC_ADMIN.

>
> Security modeling - CAP_ML

First, the name you've chosen makes no sense at all. It isn't descriptive
and fails even as an abbreviation. Second, you aren't doing anything that
wouldn't be covered under CAP_MAC_ADMIN.

>
> 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.

It seems reasonable that being trusted with the privilege to change
the modeling policy would imply sufficient trust to change other
security states where allowed. As the Smack maintainer, and having
introduced CAP_MAC_ADMIN, I say that there's insufficient grounds to
introduce a new, single purpose capability.

>
> Signed-off-by: Greg Wettstein <greg@xxxxxxxxxxxx>
> ---
>  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
>