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.