diff mbox series

[03/13] Implement CAP_TRUST capability.

Message ID 20230710102319.19716-4-greg@enjellic.com (mailing list archive)
State Changes Requested
Delegated to: Paul Moore
Headers show
Series Implement Trusted Security Event Modeling. | expand

Commit Message

Dr. Greg July 10, 2023, 10:23 a.m. UTC
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

MAC - CAP_MAC_ADMIN

Security modeling - CAP_ML

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.

Signed-off-by: Greg Wettstein <greg@enjellic.com>
---
 include/uapi/linux/capability.h     | 6 +++++-
 security/selinux/include/classmap.h | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

Comments

Casey Schaufler Aug. 7, 2023, 8:21 p.m. UTC | #1
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.

>
> Signed-off-by: Greg Wettstein <greg@enjellic.com>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 2 +-
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index 3d61a0ae055d..4a17c9774505 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -417,7 +417,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_CHECKPOINT_RESTORE	40
>  
> -#define CAP_LAST_CAP         CAP_CHECKPOINT_RESTORE
> +/* Allow modifications to the trust status of the system */
> +
> +#define CAP_ML	41
> +
> +#define CAP_LAST_CAP         CAP_ML
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a3c380775d41..f367c269bbdb 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -30,7 +30,7 @@
>  		"wake_alarm", "block_suspend", "audit_read", "perfmon", "bpf", \
>  		"checkpoint_restore"
>  
> -#if CAP_LAST_CAP > CAP_CHECKPOINT_RESTORE
> +#if CAP_LAST_CAP > CAP_ML
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>
Dr. Greg Aug. 15, 2023, 10:19 a.m. UTC | #2
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.

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

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

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.

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.

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.

Finally.

TSEM brings with it the ability to allow the creation of security
control namespaces that do not conflict with other security
namespaces, 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.

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.

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.

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.

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.

Best wishes for a productive remainder of the week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
Casey Schaufler Aug. 15, 2023, 5:15 p.m. UTC | #3
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
diff mbox series

Patch

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 3d61a0ae055d..4a17c9774505 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -417,7 +417,11 @@  struct vfs_ns_cap_data {
 
 #define CAP_CHECKPOINT_RESTORE	40
 
-#define CAP_LAST_CAP         CAP_CHECKPOINT_RESTORE
+/* Allow modifications to the trust status of the system */
+
+#define CAP_ML	41
+
+#define CAP_LAST_CAP         CAP_ML
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index a3c380775d41..f367c269bbdb 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -30,7 +30,7 @@ 
 		"wake_alarm", "block_suspend", "audit_read", "perfmon", "bpf", \
 		"checkpoint_restore"
 
-#if CAP_LAST_CAP > CAP_CHECKPOINT_RESTORE
+#if CAP_LAST_CAP > CAP_ML
 #error New capability defined, please update COMMON_CAP2_PERMS.
 #endif