| c8321831 | 03-Dec-2025 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'ipe-pr-20251202' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe
Pull IPE udates from Fan Wu: "The primary change is the addition of support for the AT_EXECVE_CHECK flag. Th
Merge tag 'ipe-pr-20251202' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe
Pull IPE udates from Fan Wu: "The primary change is the addition of support for the AT_EXECVE_CHECK flag. This allows interpreters to signal the kernel to perform IPE security checks on script files before execution, extending IPE enforcement to indirectly executed scripts.
Update documentation for it, and also fix a comment"
* tag 'ipe-pr-20251202' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe: ipe: Update documentation for script enforcement ipe: Add AT_EXECVE_CHECK support for script enforcement ipe: Drop a duplicated CONFIG_ prefix in the ifdeffery
show more ...
|
| 67678189 | 06-Nov-2025 |
Yanzhu Huang <yanzhuhuang@linux.microsoft.com> |
ipe: Add AT_EXECVE_CHECK support for script enforcement
This patch adds a new ipe_bprm_creds_for_exec() hook that integrates with the AT_EXECVE_CHECK mechanism. To enable script enforcement, interpr
ipe: Add AT_EXECVE_CHECK support for script enforcement
This patch adds a new ipe_bprm_creds_for_exec() hook that integrates with the AT_EXECVE_CHECK mechanism. To enable script enforcement, interpreters need to incorporate the AT_EXECVE_CHECK flag when calling execveat() on script files before execution.
When a userspace interpreter calls execveat() with the AT_EXECVE_CHECK flag, this hook triggers IPE policy evaluation on the script file. The hook only triggers IPE when bprm->is_check is true, ensuring it's being called from an AT_EXECVE_CHECK context. It then builds an evaluation context for an IPE_OP_EXEC operation and invokes IPE policy. The kernel returns the policy decision to the interpreter, which can then decide whether to proceed with script execution.
This extends IPE enforcement to indirectly executed scripts, permitting trusted scripts to execute while denying untrusted ones.
Signed-off-by: Yanzhu Huang <yanzhuhuang@linux.microsoft.com> Signed-off-by: Fan Wu <wufan@kernel.org>
show more ...
|
| f40998a8 | 27-Sep-2024 |
Luca Boccassi <bluca@debian.org> |
ipe: fallback to platform keyring also if key in trusted keyring is rejected
If enabled, we fallback to the platform keyring if the trusted keyring doesn't have the key used to sign the ipe policy.
ipe: fallback to platform keyring also if key in trusted keyring is rejected
If enabled, we fallback to the platform keyring if the trusted keyring doesn't have the key used to sign the ipe policy. But if pkcs7_verify() rejects the key for other reasons, such as usage restrictions, we do not fallback. Do so, following the same change in dm-verity.
Signed-off-by: Luca Boccassi <bluca@debian.org> Suggested-by: Serge Hallyn <serge@hallyn.com> [FW: fixed some line length issues and a typo in the commit message] Signed-off-by: Fan Wu <wufan@kernel.org>
show more ...
|
| 02e2f9aa | 15-Sep-2024 |
Luca Boccassi <bluca@debian.org> |
ipe: allow secondary and platform keyrings to install/update policies
The current policy management makes it impossible to use IPE in a general purpose distribution. In such cases the users are not
ipe: allow secondary and platform keyrings to install/update policies
The current policy management makes it impossible to use IPE in a general purpose distribution. In such cases the users are not building the kernel, the distribution is, and access to the private key included in the trusted keyring is, for obvious reason, not available. This means that users have no way to enable IPE, since there will be no built-in generic policy, and no access to the key to sign updates validated by the trusted keyring.
Just as we do for dm-verity, kernel modules and more, allow the secondary and platform keyrings to also validate policies. This allows users enrolling their own keys in UEFI db or MOK to also sign policies, and enroll them. This makes it sensible to enable IPE in general purpose distributions, as it becomes usable by any user wishing to do so. Keys in these keyrings can already load kernels and kernel modules, so there is no security downgrade.
Add a kconfig each, like dm-verity does, but default to enabled if the dependencies are available.
Signed-off-by: Luca Boccassi <bluca@debian.org> Reviewed-by: Serge Hallyn <serge@hallyn.com> [FW: fixed some style issues] Signed-off-by: Fan Wu <wufan@kernel.org>
show more ...
|
| 5ceecb30 | 25-Sep-2024 |
Luca Boccassi <bluca@debian.org> |
ipe: also reject policy updates with the same version
Currently IPE accepts an update that has the same version as the policy being updated, but it doesn't make it a no-op nor it checks that the old
ipe: also reject policy updates with the same version
Currently IPE accepts an update that has the same version as the policy being updated, but it doesn't make it a no-op nor it checks that the old and new policyes are the same. So it is possible to change the content of a policy, without changing its version. This is very confusing from userspace when managing policies. Instead change the update logic to reject updates that have the same version with ESTALE, as that is much clearer and intuitive behaviour.
Signed-off-by: Luca Boccassi <bluca@debian.org> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Fan Wu <wufan@kernel.org>
show more ...
|
| 10ca05a7 | 03-Aug-2024 |
Deven Bowers <deven.desai@linux.microsoft.com> |
ipe: kunit test for parser
Add various happy/unhappy unit tests for both IPE's policy parser.
Besides, a test suite for IPE functionality is available at https://github.com/microsoft/ipe/tree/test-
ipe: kunit test for parser
Add various happy/unhappy unit tests for both IPE's policy parser.
Besides, a test suite for IPE functionality is available at https://github.com/microsoft/ipe/tree/test-suite
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com> Signed-off-by: Fan Wu <wufan@linux.microsoft.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
show more ...
|
| ba199dc9 | 03-Aug-2024 |
Deven Bowers <deven.desai@linux.microsoft.com> |
scripts: add boot policy generation program
Enables an IPE policy to be enforced from kernel start, enabling access control based on trust from kernel startup. This is accomplished by transforming a
scripts: add boot policy generation program
Enables an IPE policy to be enforced from kernel start, enabling access control based on trust from kernel startup. This is accomplished by transforming an IPE policy indicated by CONFIG_IPE_BOOT_POLICY into a c-string literal that is parsed at kernel startup as an unsigned policy.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com> Signed-off-by: Fan Wu <wufan@linux.microsoft.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
show more ...
|
| 31f8c868 | 03-Aug-2024 |
Fan Wu <wufan@linux.microsoft.com> |
ipe: enable support for fs-verity as a trust provider
Enable IPE policy authors to indicate trust for a singular fsverity file, identified by the digest information, through "fsverity_digest" and al
ipe: enable support for fs-verity as a trust provider
Enable IPE policy authors to indicate trust for a singular fsverity file, identified by the digest information, through "fsverity_digest" and all files using valid fsverity builtin signatures via "fsverity_signature".
This enables file-level integrity claims to be expressed in IPE, allowing individual files to be authorized, giving some flexibility for policy authors. Such file-level claims are important to be expressed for enforcing the integrity of packages, as well as address some of the scalability issues in a sole dm-verity based solution (# of loop back devices, etc).
This solution cannot be done in userspace as the minimum threat that IPE should mitigate is an attacker downloads malicious payload with all required dependencies. These dependencies can lack the userspace check, bypassing the protection entirely. A similar attack succeeds if the userspace component is replaced with a version that does not perform the check. As a result, this can only be done in the common entry point - the kernel.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com> Signed-off-by: Fan Wu <wufan@linux.microsoft.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
show more ...
|
| e155858d | 03-Aug-2024 |
Deven Bowers <deven.desai@linux.microsoft.com> |
ipe: add support for dm-verity as a trust provider
Allows author of IPE policy to indicate trust for a singular dm-verity volume, identified by roothash, through "dmverity_roothash" and all signed a
ipe: add support for dm-verity as a trust provider
Allows author of IPE policy to indicate trust for a singular dm-verity volume, identified by roothash, through "dmverity_roothash" and all signed and validated dm-verity volumes, through "dmverity_signature".
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com> Signed-off-by: Fan Wu <wufan@linux.microsoft.com> [PM: fixed some line length issues in the comments] Signed-off-by: Paul Moore <paul@paul-moore.com>
show more ...
|