Message-ID: <553358e7-1bd7-c416-0e0f-ee504c0d0c66@schaufler-ca.com>
Date:   Mon, 13 Feb 2023 10:02:16 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [PATCH 04/14] Implement CAP_TRUST capability.
Content-Language: en-US
To:     "Dr. Greg" <greg@enjellic.com>
Cc:     linux-security-module@vger.kernel.org,
        linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
        shallyn@cisco.com, corbet@lwn.net, casey@schaufler-ca.com
References: <20230204050954.11583-1-greg@enjellic.com>
 <20230204050954.11583-5-greg@enjellic.com>
 <a12483d1-9d57-d429-789b-9e47ff575546@schaufler-ca.com>
 <20230213114313.GA15496@wind.enjellic.com>
From:   Casey Schaufler <casey@schaufler-ca.com>
In-Reply-To: <20230213114313.GA15496@wind.enjellic.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2/13/2023 3:43 AM, Dr. Greg wrote:
> 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.

There's nothing fundamentally new here. You are claiming the common
practice of looking at the audit trail to develop "policy" is a new
"alternative notion" for security. You are familiar with SELinux's
audit2allow I assume.

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

I read this as an argument for using CAP_MAC_ADMIN.

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

This is (to my simple mind) indistinguishable from the way SELinux is
used in distributions. SELinux does not require a CAP_TRUST, and only
uses CAP_MAC_ADMIN in certain unlikely error conditions which I believe
you don't encounter.

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

If you're giving the workload process chain the ability to modify the
configuration of another LSM you are already on marshy ground.

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