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.
