Message-ID: <20230213114313.GA15496@wind.enjellic.com>
Date:   Mon, 13 Feb 2023 05:43:14 -0600
From:   "Dr. Greg" <greg@...ellic.com>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     linux-security-module@...r.kernel.org,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        shallyn@...co.com, corbet@....net
Subject: Re: [PATCH 04/14] Implement CAP_TRUST capability.

On Sat, Feb 04, 2023 at 06:54:20PM -0800, Casey Schaufler wrote:

Looping in some others, given that this issue is fundamental to
influencing how Linux can do security, also Sergey who raised a
similar issue to Casey.

Apologies for the delay in responding to this, catching up on issues
after a week of travel.

> On 2/3/2023 9:09 PM, 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 privileged assets on the platform.
> >
> > Introduce the CAP_TRUST capability that is defined as a
> > capability that allows a process to alter the trust status of the
> > platform.  In a fully trust orchestrated system only the
> > orchestrators carry this capability bit.

> How is this distinguishable from CAP_MAC_ADMIN?

CAP_TRUST is being introduced to enable Linux security architects to
ontologically differentiate processes that are allowed to modify
security guarantees based on deontological (rule-based) predicates
from processes allowed to modify security guarantees that are based on
narratival (event-based) predicates.

More generally, but less accurately, it allows security architectures
to be shaped by both Kantian and Hegelian logic perspectives. [0]

Given that the above will probably not be seen as an overly compelling
argument, in and of itself .... :-), some technical observations in
support of CAP_TRUST

Dictating to the choir here, but a brief background for those
following this discussion with an interest in security issues.

In general, classic mandatory access controls (MAC) are policy based.
For example, the standard bearers, SMACK and SeLinux, use classic
subject/object philosophies.  A process (subject) has a role/label
attached to it and objects acted on by the processes have a label
associated with them.  Policies, that can be viewed as rules, usually
quite elaborate and detailed for a whole system security policy, are
developed that define how subject labels may or may not interact with
object labels.

TSEM introduces an alternate notion of a security policy, defined as a
security model in TSEM parlance, that is created by unit testing of a
platform or workload.  Precise descriptions of the security events
generated by the testing are captured and used to maintain subsequent
executions of the workload in a known security or trust state.

Both approaches are considered 'mandatory' in nature, since userspace
cannot modify, in the case of policy based systems the labeling, or in
event based systems the security model being enforced.  Unless of
course a process has been assigned the capability to do so, hence this
discussion.

We are proposing CAP_TRUST as the privilege that is required by
processes to maintain the security state of a workload based on a set
of known valid security events.  In theory, and practice, it is
orthogonal to the actions permitted by CAP_MAC_ADMIN.  Although,
obviously, the intent of all these systems is to maintain a known
security state, however different those schemes may be from a
methodological perspective.

In security architectures, the concept of 'trust' has connotated the
notion of having a cryptographic guarantee of the state of a system.
As the cover letter and documentation discuss, TSEM is about blending
integrity measurement and mandatory access controls.

Trust orchestrators are designed to provide an attestation that a
workload has not deviated in any way from a previously defined
security model, CAP_TRUST is the privilege required to influence this
guarantee.  Once again, we view this as a different concept and
objective than the ability to modify a security policy.

Perhaps most importantly, TSEM shouldn't be viewed as an either/or
proposition when it comes to classic subject/object MAC
implementations.  A differentiation between CAP_TRUST and
CAP_MAC_ADMIN is needed in order to allow both architectures to work
together in a collaborative fashion.

It would be perfectly reasonable to believe that a TSEM modeled
workload would implement MAC (rules based) security controls.  In
order to achieve event based security guarantees, a trust orchestrator
drops CAP_TRUST for the workload process chain.  If CAP_MAC_ADMIN were
used, it would potentially impair the ability of the workload to
implement MAC policies, hence the desire to keep the privileges
orthogonal.

A quick example as to why this may be relevant.

Since TSEM is a generic security modeling architecture, with full
access to all security events, it can model the integrity of the
security meta-data needed by MAC based policies, similar to what
IMA/EVM does now, but entirely in the context of the LSM architecture
itself.  It would therefore be reasonable to operate both security
architectures in unison, with the event based TSEM protecting the
rules based MAC implementation.

Hopefully all of this helps clarify our thinking on this.

After reviewing the TSEM ABI and documentation, Paul Moore had some
questions and requests for clarification.  I am composing a response
to that e-mail that may also assist in understanding the role for
CAP_TRUST.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity

[0]: In the interest of full disclosure, I need to officially
attribute the notion of the philosophical differences between the two
security architectures to a brilliant young cybersecurity engineer
that I was privileged to mentor in the field of security modeling.  We
struggled for a long time to explain why and how TSEM was different
until he offered this inspired reasoning.  I recognize him, but will
leave him anonymous due to his current roles and responsibilities.

Powered by blists - more mailing lists