Re: [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE)
On 10/27/2021 1:26 AM, Roberto Sassu wrote: From: Deven Bowers [mailto:deven.de...@linux.microsoft.com] Sent: Tuesday, October 26, 2021 9:04 PM On 10/25/2021 4:30 AM, Roberto Sassu wrote: From:deven.de...@linux.microsoft.com [mailto:deven.de...@linux.microsoft.com] From: Deven Bowers Overview: - IPE is a Linux Security Module which takes a complimentary approach to access control. Whereas existing systems approach use labels or paths which control access to a resource, IPE controls access to a resource based on the system's trust of said resource. To me, it does not give a particularly precise idea of what IPE is about. It would have been more clear, assuming that I understood it correctly, if you have said: Whereas existing mandatory access control mechanisms base their decisions on labels and paths, IPE instead determines whether or not an operation should be allowed based on immutable security properties of the system component the operation is being performed on. IPE itself does not mandate how the security property should be evaluated, but relies on an extensible set of external property providers to evaluate the component. IPE makes its decision based on reference values for the selected properties, specified in the IPE policy. The reference values represent the value that the policy writer and the local system administrator (based on the policy signature) trust for the system to accomplish the desired tasks. One such provider is for example dm-verity, which is able to represent the integrity property of a partition (its immutable state) with a digest. You understood it perfectly, and managed to word in a much more clear way than I did. I'll apply these changes in the next posting! Thanks. Welcome. Trust requirements are established via IPE's policy, sourcing multiple different implementations within the kernel to build a cohesive trust model, based on how the system was built. Trust, with respect to computing, is a concept that designates a set of entities who will endorse a set of resources as non-malicious. Traditionally, this is done via signatures, which is the act of endorsing a resource. Integrity, on the other hand, is the concept of ensuring that a resource has not been modified since a point of time. This is typically done through cryptographic hashes or signatures. Trust and integrity are very closely tied together concepts, as integrity is the way you can prove trust for a resource; otherwise it could have been modified by an entity who is untrusted. IPE provides a way for a user to express trust requirements of resources, by using pre-existing systems which provide the integrity half of the equation. IPE is compiled under CONFIG_SECURITY_IPE. Use Cases - IPE works best in fixed-function devices: Devices in which their purpose is clearly defined and not supposed to be changed (e.g. network firewall device in a data center, an IoT device, etcetera), where all software and configuration is built and provisioned by the system owner. IPE is a long-way off for use in general-purpose computing: the Linux community as a whole tends to follow a decentralized trust model, known as the Web of Trust, which IPE has no support for as of yet. Instead, IPE supports the PKI Trust Model, which generally designates a set of entities that provide a measure absolute trust. It is true that packages are signed with PGP, which is decentralized, but there is a special case where Linux distribution vendors trust their own keys. This, at least, would allow to trust the software built by a particular vendor (I ported David Howells's work on PGP keys and signature to the current kernel). Yes, that is true. I figured that this scenario was somewhat obvious, as it is, at a high level, similar to PKI but I can certainly add it explicitly. Perfect. Additionally, while most packages are signed today, the files inside the packages (for instance, the executables), tend to be unsigned. This makes it difficult to utilize IPE in systems where a package manager is expected to be functional, without major changes to the package manager and ecosystem behind it. Yes, RPMs don't have per file signatures but have a signature of the list of file digests, which is equivalent. They could have also the fsverity digests (instead of the fsverity signatures) to reduce size overhead. Given that the authenticity of RPMs headers can be verified, if the PGP key of the vendor is included in the primary keyring of the kernel, being able to protect file or fsverity digests against tampering by user space and being able to query them (e.g. with DIGLIM) extends the applicability of IPE to general purpose OSes. Agreed. With these two functionalities, it does appear that IPE + DIGLIM can be used for general purpose RPM-based OSes. I'll add a reference to your recent posting (v3?) as a way to extend the functionality to general purposes OSes in the next revision. Ok. Yes, v3 is the latest. Policy:
RE: [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE)
> From: Deven Bowers [mailto:deven.de...@linux.microsoft.com] > Sent: Tuesday, October 26, 2021 9:04 PM > On 10/25/2021 4:30 AM, Roberto Sassu wrote: > >> From:deven.de...@linux.microsoft.com > >> [mailto:deven.de...@linux.microsoft.com] > >> From: Deven Bowers > >> > >> Overview: > >> - > >> > >> IPE is a Linux Security Module which takes a complimentary approach to > >> access control. Whereas existing systems approach use labels or paths > >> which control access to a resource, IPE controls access to a resource > >> based on the system's trust of said resource. > > To me, it does not give a particularly precise idea of what IPE is about. > > > > It would have been more clear, assuming that I understood it correctly, > > if you have said: > > > > Whereas existing mandatory access control mechanisms base their > > decisions on labels and paths, IPE instead determines whether or not > > an operation should be allowed based on immutable security properties > > of the system component the operation is being performed on. > > > > IPE itself does not mandate how the security property should be > > evaluated, but relies on an extensible set of external property providers > > to evaluate the component. IPE makes its decision based on reference > > values for the selected properties, specified in the IPE policy. > > > > The reference values represent the value that the policy writer and the > > local system administrator (based on the policy signature) trust for the > > system to accomplish the desired tasks. > > > > One such provider is for example dm-verity, which is able to represent > > the integrity property of a partition (its immutable state) with a digest. > You understood it perfectly, and managed to word in a much more clear > way than I did. I'll apply these changes in the next posting! Thanks. Welcome. > >> Trust requirements are established via IPE's policy, sourcing multiple > >> different implementations within the kernel to build a cohesive trust > >> model, based on how the system was built. > >> > >> Trust, with respect to computing, is a concept that designates a set > >> of entities who will endorse a set of resources as non-malicious. > >> Traditionally, this is done via signatures, which is the act of endorsing > >> a resource. > >> > >> Integrity, on the other hand, is the concept of ensuring that a resource > >> has not been modified since a point of time. This is typically done through > >> cryptographic hashes or signatures. > >> > >> Trust and integrity are very closely tied together concepts, as integrity > >> is the way you can prove trust for a resource; otherwise it could have > >> been modified by an entity who is untrusted. > >> > >> IPE provides a way for a user to express trust requirements of resources, > >> by using pre-existing systems which provide the integrity half of the > >> equation. > >> > >> IPE is compiled under CONFIG_SECURITY_IPE. > >> > >> Use Cases > >> - > >> > >> IPE works best in fixed-function devices: Devices in which their purpose > >> is clearly defined and not supposed to be changed (e.g. network firewall > >> device in a data center, an IoT device, etcetera), where all software and > >> configuration is built and provisioned by the system owner. > >> > >> IPE is a long-way off for use in general-purpose computing: > >> the Linux community as a whole tends to follow a decentralized trust > >> model, known as the Web of Trust, which IPE has no support for as of yet. > >> Instead, IPE supports the PKI Trust Model, which generally designates a > >> set of entities that provide a measure absolute trust. > > It is true that packages are signed with PGP, which is decentralized, > > but there is a special case where Linux distribution vendors trust > > their own keys. This, at least, would allow to trust the software built > > by a particular vendor (I ported David Howells's work on PGP keys and > > signature to the current kernel). > Yes, that is true. I figured that this scenario was somewhat obvious, > as it is, at a high level, similar to PKI but I can certainly add it > explicitly. Perfect. > >> Additionally, while most packages are signed today, the files inside > >> the packages (for instance, the executables), tend to be unsigned. This > >> makes it difficult to utilize IPE in systems where a package manager is > >> expected to be functional, without major changes to the package manager > >> and ecosystem behind it. > > Yes, RPMs don't have per file signatures but have a signature of the > > list of file digests, which is equivalent. They could have also the fsverity > > digests (instead of the fsverity signatures) to reduce size overhead. > > > > Given that the authenticity of RPMs headers can be verified, if the > > PGP key of the vendor is included in the primary keyring of the kernel, > > being able to protect file or fsverity digests against tampering by > > user space and being able to query them (e.g. with DIGLIM) extends > >
Re: [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE)
On 10/25/2021 4:30 AM, Roberto Sassu wrote: From:deven.de...@linux.microsoft.com [mailto:deven.de...@linux.microsoft.com] From: Deven Bowers Overview: - IPE is a Linux Security Module which takes a complimentary approach to access control. Whereas existing systems approach use labels or paths which control access to a resource, IPE controls access to a resource based on the system's trust of said resource. To me, it does not give a particularly precise idea of what IPE is about. It would have been more clear, assuming that I understood it correctly, if you have said: Whereas existing mandatory access control mechanisms base their decisions on labels and paths, IPE instead determines whether or not an operation should be allowed based on immutable security properties of the system component the operation is being performed on. IPE itself does not mandate how the security property should be evaluated, but relies on an extensible set of external property providers to evaluate the component. IPE makes its decision based on reference values for the selected properties, specified in the IPE policy. The reference values represent the value that the policy writer and the local system administrator (based on the policy signature) trust for the system to accomplish the desired tasks. One such provider is for example dm-verity, which is able to represent the integrity property of a partition (its immutable state) with a digest. You understood it perfectly, and managed to word in a much more clear way than I did. I'll apply these changes in the next posting! Thanks. Trust requirements are established via IPE's policy, sourcing multiple different implementations within the kernel to build a cohesive trust model, based on how the system was built. Trust, with respect to computing, is a concept that designates a set of entities who will endorse a set of resources as non-malicious. Traditionally, this is done via signatures, which is the act of endorsing a resource. Integrity, on the other hand, is the concept of ensuring that a resource has not been modified since a point of time. This is typically done through cryptographic hashes or signatures. Trust and integrity are very closely tied together concepts, as integrity is the way you can prove trust for a resource; otherwise it could have been modified by an entity who is untrusted. IPE provides a way for a user to express trust requirements of resources, by using pre-existing systems which provide the integrity half of the equation. IPE is compiled under CONFIG_SECURITY_IPE. Use Cases - IPE works best in fixed-function devices: Devices in which their purpose is clearly defined and not supposed to be changed (e.g. network firewall device in a data center, an IoT device, etcetera), where all software and configuration is built and provisioned by the system owner. IPE is a long-way off for use in general-purpose computing: the Linux community as a whole tends to follow a decentralized trust model, known as the Web of Trust, which IPE has no support for as of yet. Instead, IPE supports the PKI Trust Model, which generally designates a set of entities that provide a measure absolute trust. It is true that packages are signed with PGP, which is decentralized, but there is a special case where Linux distribution vendors trust their own keys. This, at least, would allow to trust the software built by a particular vendor (I ported David Howells's work on PGP keys and signature to the current kernel). Yes, that is true. I figured that this scenario was somewhat obvious, as it is, at a high level, similar to PKI but I can certainly add it explicitly. Additionally, while most packages are signed today, the files inside the packages (for instance, the executables), tend to be unsigned. This makes it difficult to utilize IPE in systems where a package manager is expected to be functional, without major changes to the package manager and ecosystem behind it. Yes, RPMs don't have per file signatures but have a signature of the list of file digests, which is equivalent. They could have also the fsverity digests (instead of the fsverity signatures) to reduce size overhead. Given that the authenticity of RPMs headers can be verified, if the PGP key of the vendor is included in the primary keyring of the kernel, being able to protect file or fsverity digests against tampering by user space and being able to query them (e.g. with DIGLIM) extends the applicability of IPE to general purpose OSes. Agreed. With these two functionalities, it does appear that IPE + DIGLIM can be used for general purpose RPM-based OSes. I'll add a reference to your recent posting (v3?) as a way to extend the functionality to general purposes OSes in the next revision. Policy: --- IPE policy is a plain-text [#]_ policy composed of multiple statements over several lines. There is one required line, at the top of the policy, indicating the policy name, and the policy
RE: [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE)
> From: deven.de...@linux.microsoft.com > [mailto:deven.de...@linux.microsoft.com] > From: Deven Bowers > > Overview: > - > > IPE is a Linux Security Module which takes a complimentary approach to > access control. Whereas existing systems approach use labels or paths > which control access to a resource, IPE controls access to a resource > based on the system's trust of said resource. To me, it does not give a particularly precise idea of what IPE is about. It would have been more clear, assuming that I understood it correctly, if you have said: Whereas existing mandatory access control mechanisms base their decisions on labels and paths, IPE instead determines whether or not an operation should be allowed based on immutable security properties of the system component the operation is being performed on. IPE itself does not mandate how the security property should be evaluated, but relies on an extensible set of external property providers to evaluate the component. IPE makes its decision based on reference values for the selected properties, specified in the IPE policy. The reference values represent the value that the policy writer and the local system administrator (based on the policy signature) trust for the system to accomplish the desired tasks. One such provider is for example dm-verity, which is able to represent the integrity property of a partition (its immutable state) with a digest. > Trust requirements are established via IPE's policy, sourcing multiple > different implementations within the kernel to build a cohesive trust > model, based on how the system was built. > > Trust, with respect to computing, is a concept that designates a set > of entities who will endorse a set of resources as non-malicious. > Traditionally, this is done via signatures, which is the act of endorsing > a resource. > > Integrity, on the other hand, is the concept of ensuring that a resource > has not been modified since a point of time. This is typically done through > cryptographic hashes or signatures. > > Trust and integrity are very closely tied together concepts, as integrity > is the way you can prove trust for a resource; otherwise it could have > been modified by an entity who is untrusted. > > IPE provides a way for a user to express trust requirements of resources, > by using pre-existing systems which provide the integrity half of the > equation. > > IPE is compiled under CONFIG_SECURITY_IPE. > > Use Cases > - > > IPE works best in fixed-function devices: Devices in which their purpose > is clearly defined and not supposed to be changed (e.g. network firewall > device in a data center, an IoT device, etcetera), where all software and > configuration is built and provisioned by the system owner. > > IPE is a long-way off for use in general-purpose computing: > the Linux community as a whole tends to follow a decentralized trust > model, known as the Web of Trust, which IPE has no support for as of yet. > Instead, IPE supports the PKI Trust Model, which generally designates a > set of entities that provide a measure absolute trust. It is true that packages are signed with PGP, which is decentralized, but there is a special case where Linux distribution vendors trust their own keys. This, at least, would allow to trust the software built by a particular vendor (I ported David Howells's work on PGP keys and signature to the current kernel). > Additionally, while most packages are signed today, the files inside > the packages (for instance, the executables), tend to be unsigned. This > makes it difficult to utilize IPE in systems where a package manager is > expected to be functional, without major changes to the package manager > and ecosystem behind it. Yes, RPMs don't have per file signatures but have a signature of the list of file digests, which is equivalent. They could have also the fsverity digests (instead of the fsverity signatures) to reduce size overhead. Given that the authenticity of RPMs headers can be verified, if the PGP key of the vendor is included in the primary keyring of the kernel, being able to protect file or fsverity digests against tampering by user space and being able to query them (e.g. with DIGLIM) extends the applicability of IPE to general purpose OSes. > Policy: > --- > > IPE policy is a plain-text [#]_ policy composed of multiple statements > over several lines. There is one required line, at the top of the > policy, indicating the policy name, and the policy version, for > instance: > > policy_name="Ex Policy" policy_version=0.0.0 > > The policy version indicates the current version of the policy (NOT the > policy syntax version). This is used to prevent roll-back of policy to > potentially insecure previous versions of the policy. > > The next portion of IPE policy, are rules. Rules are formed by key=value > pairs, known as properties. IPE rules require two properties: "action", Better: IPE rules require two keys: >
