Re: [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE)
On Thu, Feb 02, 2023 at 11:48:18AM +0100, Roberto Sassu wrote: > On Tue, 2023-01-31 at 16:48 -0800, Fan Wu wrote: > > On Tue, Jan 31, 2023 at 03:22:05PM +0100, Roberto Sassu wrote: > > > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote: > > > > IPE has two known gaps: > > > > > > > > 1. IPE cannot verify the integrity of anonymous executable memory, such > > > > as > > > > the trampolines created by gcc closures and libffi (<3.4.2), or JIT'd > > > > code. > > > > Unfortunately, as this is dynamically generated code, there is no way > > > > for IPE to ensure the integrity of this code to form a trust basis. > > > > In all > > > > cases, the return result for these operations will be whatever the > > > > admin > > > > configures the DEFAULT action for "EXECUTE". > > > > > > I think it would be useful to handle special cases, for example you > > > could allow a process that created a file with memfd to use it, at the > > > condition that nobody else writes it. > > > > > > This would be required during the boot, otherwise services could fail > > > to start (depending on the policy). > > > > > Thanks for the suggestion. I agree with your opinion and I think supporting > > memfd is possible but restricting read/write needs more hooks. We would like > > to avoid adding more complexity to this initial posting as necessary. > > We will consider this as a future work and will post follow-on patches > > in the future. > > Ok, maybe it is necessary to specify better the scope of IPE, why the > current implementation can be considered as complete. > > If we say, IPE can only allow/deny operations on system components with > immutable security properties, clearly memfd as a component cannot > fullfill this goal due to the non-immutability. This would apply to any > component allowing modifications. > > How to address this? What is the immutable property then? > > In the case of memfd, intuitively, a useful property for integrity > could be for example that the content can be accessed/modified by only > one process. No other (possibly malicious) processes can tamper with > that file. > > So, it is true, to make this property immutable more hooks are needed. > But should it be something that IPE does? Or it should be done by an > external component (another LSM) that does the enforcement and reports > to IPE that the property is true? Theoretically (with a proper policy), > existing LSMs could be used for that purpose too. > > I would say more the second, it should not be IPE job, so that IPE can > exclusively focus on evaluating properties, not making sure that the > properties are immutable. > > Roberto > I think the issue here is not about the scope of IPE but the use cases of IPE. We use IPE on fixed-function devices, which are completely locked down. In our system, IPE denies all anonymous memory execution so memfd will not work on our system. Therefore, to make memfd useable with IPE we must add more properties. -Fan -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE)
On Tue, 2023-01-31 at 16:48 -0800, Fan Wu wrote: > On Tue, Jan 31, 2023 at 03:22:05PM +0100, Roberto Sassu wrote: > > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote: > > > IPE has two known gaps: > > > > > > 1. IPE cannot verify the integrity of anonymous executable memory, such as > > > the trampolines created by gcc closures and libffi (<3.4.2), or JIT'd > > > code. > > > Unfortunately, as this is dynamically generated code, there is no way > > > for IPE to ensure the integrity of this code to form a trust basis. In > > > all > > > cases, the return result for these operations will be whatever the admin > > > configures the DEFAULT action for "EXECUTE". > > > > I think it would be useful to handle special cases, for example you > > could allow a process that created a file with memfd to use it, at the > > condition that nobody else writes it. > > > > This would be required during the boot, otherwise services could fail > > to start (depending on the policy). > > > Thanks for the suggestion. I agree with your opinion and I think supporting > memfd is possible but restricting read/write needs more hooks. We would like > to avoid adding more complexity to this initial posting as necessary. > We will consider this as a future work and will post follow-on patches > in the future. Ok, maybe it is necessary to specify better the scope of IPE, why the current implementation can be considered as complete. If we say, IPE can only allow/deny operations on system components with immutable security properties, clearly memfd as a component cannot fullfill this goal due to the non-immutability. This would apply to any component allowing modifications. How to address this? What is the immutable property then? In the case of memfd, intuitively, a useful property for integrity could be for example that the content can be accessed/modified by only one process. No other (possibly malicious) processes can tamper with that file. So, it is true, to make this property immutable more hooks are needed. But should it be something that IPE does? Or it should be done by an external component (another LSM) that does the enforcement and reports to IPE that the property is true? Theoretically (with a proper policy), existing LSMs could be used for that purpose too. I would say more the second, it should not be IPE job, so that IPE can exclusively focus on evaluating properties, not making sure that the properties are immutable. Roberto > -Fan > > > > 2. IPE cannot verify the integrity of interpreted languages' programs when > > > these scripts invoked via `` ``. This is because the > > > way interpreters execute these files, the scripts themselves are not > > > evaluated as executable code through one of IPE's hooks. Interpreters > > > can be enlightened to the usage of IPE by trying to mmap a file into > > > executable memory (+X), after opening the file and responding to the > > > error code appropriately. This also applies to included files, or high > > > value files, such as configuration files of critical system components. > > > > Ok, it is a well known issue. Hopefully, it will be fixed soon. > > > > Roberto > > -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE)
On Tue, Jan 31, 2023 at 03:22:05PM +0100, Roberto Sassu wrote: > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote: > > IPE has two known gaps: > > > > 1. IPE cannot verify the integrity of anonymous executable memory, such as > > the trampolines created by gcc closures and libffi (<3.4.2), or JIT'd > > code. > > Unfortunately, as this is dynamically generated code, there is no way > > for IPE to ensure the integrity of this code to form a trust basis. In all > > cases, the return result for these operations will be whatever the admin > > configures the DEFAULT action for "EXECUTE". > > I think it would be useful to handle special cases, for example you > could allow a process that created a file with memfd to use it, at the > condition that nobody else writes it. > > This would be required during the boot, otherwise services could fail > to start (depending on the policy). > Thanks for the suggestion. I agree with your opinion and I think supporting memfd is possible but restricting read/write needs more hooks. We would like to avoid adding more complexity to this initial posting as necessary. We will consider this as a future work and will post follow-on patches in the future. -Fan > > 2. IPE cannot verify the integrity of interpreted languages' programs when > > these scripts invoked via `` ``. This is because the > > way interpreters execute these files, the scripts themselves are not > > evaluated as executable code through one of IPE's hooks. Interpreters > > can be enlightened to the usage of IPE by trying to mmap a file into > > executable memory (+X), after opening the file and responding to the > > error code appropriately. This also applies to included files, or high > > value files, such as configuration files of critical system components. > > Ok, it is a well known issue. Hopefully, it will be fixed soon. > > Roberto > -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE)
On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote: > Overview: > - > > IPE is a Linux Security Module which takes a complimentary approach to > access control. 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. > > 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. > There are exceptions, such as the case where a Linux distribution > vendor trusts only their own keys, where IPE can successfully be used > to enforce the trust requirement. > > 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. > > DIGLIM[1] is a system that when combined with IPE, could be used to > enable general purpose computing scenarios. > > 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. 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 keys: "action", which > determines what IPE does when it encounters a match against the policy > and "op", which determines when that rule should be evaluated. > > Thus, a minimal rule is: > > op=EXECUTE action=ALLOW > > This example rule will allow any execution. A rule is required to have the > "op" property as the first token of a rule, and the "action" as the last > token of the rule. > > Additional properties are used to restrict attributes about the files being > evaluated. These properties are intended to be deterministic attributes > that are resident in the kernel. > > For example: > > op=EXECUTE dmverity_signature=FALSE action=DENY > > This rule with property dmverity_signature will deny any file not from > a signed dmverity volume to be executed. > > All available properties for IPE described in the documentation patch of > this series. > > Rules are evaluated top-to-bottom. As a result, any revocation rules, > or denies should be placed early in the file to ensure that these rules > are evaluated before a rule with "action=ALLOW" is hit. > > Any unknown syntax in IPE policy will result in a fatal error to parse > the policy. > > Additionally, a DEFAULT operation must be set for all understood > operations within IPE. For policies to remain completely forwards > compatible, it is recommended that users add a "DEFAULT action=ALLOW" > and override the defaults on a per-operation basis. > > For more information about the policy syntax, see the kernel > documentation page. > > Early Usermode Protection: > -- > > IPE can be provided with a policy at startup to load and enforce. > This is intended to be a minimal policy to get the system to a state > where userspace is setup and ready to receive commands, at which > point a policy can be deployed via securityfs. This "boot policy" can be > specified via the config, SECURITY_IPE_BOOT_POLICY, which accepts a path > to a plain-text version of the IPE policy to apply. This policy will be > compiled into the kernel. If not specified, IPE will be disabled until a > policy is deployed and activated through
[RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE)
Overview: - IPE is a Linux Security Module which takes a complimentary approach to access control. 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. 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. There are exceptions, such as the case where a Linux distribution vendor trusts only their own keys, where IPE can successfully be used to enforce the trust requirement. 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. DIGLIM[1] is a system that when combined with IPE, could be used to enable general purpose computing scenarios. 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. 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 keys: "action", which determines what IPE does when it encounters a match against the policy and "op", which determines when that rule should be evaluated. Thus, a minimal rule is: op=EXECUTE action=ALLOW This example rule will allow any execution. A rule is required to have the "op" property as the first token of a rule, and the "action" as the last token of the rule. Additional properties are used to restrict attributes about the files being evaluated. These properties are intended to be deterministic attributes that are resident in the kernel. For example: op=EXECUTE dmverity_signature=FALSE action=DENY This rule with property dmverity_signature will deny any file not from a signed dmverity volume to be executed. All available properties for IPE described in the documentation patch of this series. Rules are evaluated top-to-bottom. As a result, any revocation rules, or denies should be placed early in the file to ensure that these rules are evaluated before a rule with "action=ALLOW" is hit. Any unknown syntax in IPE policy will result in a fatal error to parse the policy. Additionally, a DEFAULT operation must be set for all understood operations within IPE. For policies to remain completely forwards compatible, it is recommended that users add a "DEFAULT action=ALLOW" and override the defaults on a per-operation basis. For more information about the policy syntax, see the kernel documentation page. Early Usermode Protection: -- IPE can be provided with a policy at startup to load and enforce. This is intended to be a minimal policy to get the system to a state where userspace is setup and ready to receive commands, at which point a policy can be deployed via securityfs. This "boot policy" can be specified via the config, SECURITY_IPE_BOOT_POLICY, which accepts a path to a plain-text version of the IPE policy to apply. This policy will be compiled into the kernel. If not specified, IPE will be disabled until a policy is deployed and activated through the method above. Policy Examples: Allow all: policy_name=Allow_All policy_version=0.0.0 DEFAULT action=ALLOW Allow only initial superblock: policy_name=Allow_All_Initial_SB policy_version=0.0.0 DEFAULT action=DENY op=EXECUTE boot_verified=TRUE
