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

[Casey Schaufler]

On 8/15/2023 3:19 AM, Dr. Greg wrote:
> On Mon, Aug 07, 2023 at 01:21:35PM -0700, Casey Schaufler wrote:
>
> Good morning, I hope this note finds the day starting well for
> everyone.
>
>> 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.
> Our apologies, I believe we were thinking of CAP_DAC_OVERRIDE.

CAP_DAC_OVERRIDE allows you to circumvent the normal DAC checks.
It is not an administrative capability.

>
>>> MAC - CAP_MAC_ADMIN
>> Since your system implements a mandatory access control policy
>> you should be using CAP_MAC_ADMIN.
> See below.
>
>>> 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.
> Apologies for the name, we choose it ad-hoc as an acronym for 'Machine
> Learning' which is what TSEM uses, in potentially multiple forms, to
> implement its security controls.  I wouldn't anticipate it to be
> forthcoming from your corner, but feel free to suggest an alternative.

The name should be descriptive and unambiguous. CAP_SYS_ADMIN, for all
it's faults, tells you exactly what it's for, privileged administration
operations that are outside the scope of the system security mechanisms.
Your proposed capability should be named so as it make it obvious where
else in the system it could/should be used.

> You note above that CAP_MAC_ADMIN should be used because TSEM ends up
> implementing access control decsions that are mandatory in nature

That is correct.

> As our documentation notes, with the introduction of TSEM there are
> three mechanisms that are now available to implement security
> controls: DAC, static MAC and dynamic controls based on
> modeling/machine learning.

The static vs. dynamic distinction is fallacious. You can change Smack
rule sets at any time. You could easily create a modeling/machine learning
daemon that reads the syslog, audit files and various other system interfaces
and uses the data to reset the Smack rules to suit its idea of security.
That daemon would require CAP_MAC_ADMIN and sufficient privilege to read
the data it is interested in.

Having provided an example of a dynamic, modeling/machine learning system
for which CAP_MAC_ADMIN is appropriate, I remain of the opinion that your
proposed CAP_ML is unnecessary.

> Our premise for proposing a separate capability is that different
> methods of achieving security controls should use different
> capabilities, so that the capability controls remain orthogonal and
> independent of one another.

There are lots of people who agree with you. Unfortunately, the capability
mechanism does not scale well to large numbers of capabilities. It was
not designed (P1003.1e/2c) with fine grained privilege in mind. The use
of capabilities has been slow enough on the uptake as it is. Adding all
the capabilities that have been requested over the years would only make
it harder.

> Additionally.
>
> The mandatory controls implemented by TSEM are subtly different in
> intent from those implemented by the incumbent LSM's, since TSEM's
> controls can be generated and implemented by software developers or
> users.  You had noted in other replies that classic mandatory controls
> should only be implemented by system administrators or security
> architects.

Look at seccomp and landlock before you claim TSEM is unique in this way.

> Finally.
>
> TSEM brings with it the ability to allow the creation of security
> control namespaces that do not conflict with other security
> namespaces,

I read this several times, and can't tease out what it means. :(

>  with the exception that the non-namespaced controls will
> also exert their authority if they are 'stacked' with TSEM.  If we
> read user interest and expectations correctly, which I believe we do,
> there will only be an increasing demand for this type of security
> functionality.
>
> Given that, it will be problematic, moving forward, if the capability
> to create isolated security namespaces is not orthogonal with the
> ability to modify how a policy can be configured or managed within an
> isolated security namespace.

I don't see how "creating an isolated security namespace" isn't
a "configuraton" or "management" operation. You are going to have
some other mechanism to prevent processes in an isolated security
namespace from creating new isolated security namespaces if you
don't want them to, aren't you?

> Given this latter issue, CAP_ML probably needs a different name,
> once again, suggestions are welcome.
>
>>> 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.
> First, no one, least of all our group, doubts your contributions to
> the art.
>
> We are also very confident, in the level of skills and experience in
> the fields of modeling and security operations, of the team that is
> bringing forward TSEM.
>
> Based on these experiences, as we noted above, we believe it will be
> unwise to not make the ability to control the creation, isolation and
> protection of a security namespace from the ability to modify the
> configuration of a security policy within a namespace.

Sorry, again, I read this several times and can't quite parse it.

> Secondly.
>
> With respect to the capability being 'single purpose'.  We haven't
> seen a clear pathway or discussion regarding namespaces for other
> security architectures, given the known structural issues involved
> with classic labeling or pathname based implementations.  Paul
> suggests that there is ongoing thinking on how to address this issue
> and you've noted that the stacking work needs to go in before further
> functionality can be considered.

AppArmor has a working implementation. Both SELinux and Smack have had
patches reviewed in the past. SELinux work continues, but it has been a
while since there have been postings. You're correct that no clear path
has been proposed for dealing with namespaces generically.

> The new capability bit will be available when those initiatives move
> forward.  Kernel doctrine has been that at least a single use of
> functionality must be present for a feature to be added, TSEM provides
> that initial use.

Requests for single-use capabilities come in all the time. The
capability system isn't set up to allow for them.

> Finally.
>
> In his 'ANN' document, regarding LSM submission requirements, Paul
> Moore noted that he did not want to require the need to demonstrate a
> 'community of support' around an LSM in order to avoid a 'chicken and
> egg' problem.  He further noted that LSM authors need to be able to
> guarantee that API's will be durable for 20+ years.
>
> Within the security industry there is already a 'chicken and egg'
> problem.  A new security architecture or scheme will not evolve
> without the system, at a minimum, being in the Linux kernel.  New
> security architectures do not organically appear and evolve, we can
> state this fact with significant authority.
>
> Without generic availability and use of a technology, it is difficult
> to reason how correct 20+ year guesses on needed functionality can be
> made.  So there needs to be a 'guess' on how to implement technology,
> in the most generic form that does not lock the implementation into a
> corner.
>
> We've tried to make these 'guesses' with TSEM, based on, now 15+ years
> of experience, with multiple implementations of security modeling and
> namespacing.  Our advocacy for the new capability bit, whatever it is
> named, is based on that body of experience.
>
> We have proposed what we believe is the correct implementation and
> API.  If the only way forward is an alternate implementation, we have
> conducted our due diligence, which history will document if that
> alternate implementation proves to be insufficient and constraining.

Yes, I hear you. Your arguments are fine, they just don't justify
a new, single use capability.

> Best wishes for a productive remainder of the week.

To you as well.

>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity