| 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 |
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 >
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
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 --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
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(-)