summaryrefslogtreecommitdiff
path: root/Documentation/admin-guide/LSM/ipe.rst
AgeCommit message (Collapse)Author
10 daysipe: update the project and test suite linksFan Wu
IPE now has a project website at https://ipe-lsm.org/, and its integration tests are maintained in the Integrity-Policy-Enforcement/ci repository. Point the admin guide to the website, and point the test suite link in the developer documentation to the new repository. Assisted-by: LLM Signed-off-by: Fan Wu <wufan@kernel.org>
10 daysipe: fix invalid sgid value in audit event documentationManuel Ebner
The audit event example in the IPE documentation contains 'sgid=)', which is not a valid Set Group ID value. Fix it to use 'sgid=0'. Fixes: ac6731870ed9 ("documentation: add IPE documentation") Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Fan Wu <wufan@kernel.org>
2025-12-02ipe: Update documentation for script enforcementYanzhu Huang
This patch adds explanation of script enforcement mechanism in admin guide documentation. Describes how IPE supports integrity enforcement for indirectly executed scripts through the AT_EXECVE_CHECK flag, and how this differs from kernel enforcement for compiled executables. Signed-off-by: Yanzhu Huang <yanzhuhuang@linux.microsoft.com> Signed-off-by: Fan Wu <wufan@kernel.org>
2025-05-27ipe: add errno field to IPE policy load auditingJasjiv Singh
Users of IPE require a way to identify when and why an operation fails, allowing them to both respond to violations of policy and be notified of potentially malicious actions on their systems with respect to IPE. This patch introduces a new error field to the AUDIT_IPE_POLICY_LOAD event to log policy loading failures. Currently, IPE only logs successful policy loads, but not failures. Tracking failures is crucial to detect malicious attempts and ensure a complete audit trail for security events. The new error field will capture the following error codes: * -ENOKEY: Key used to sign the IPE policy not found in the keyring * -ESTALE: Attempting to update an IPE policy with an older version * -EKEYREJECTED: IPE signature verification failed * -ENOENT: Policy was deleted while updating * -EEXIST: Same name policy already deployed * -ERANGE: Policy version number overflow * -EINVAL: Policy version parsing error * -EPERM: Insufficient permission * -ENOMEM: Out of memory (OOM) * -EBADMSG: Policy is invalid Here are some examples of the updated audit record types: AUDIT_IPE_POLICY_LOAD(1422): audit: AUDIT1422 policy_name="Test_Policy" policy_version=0.0.1 policy_digest=sha256:84EFBA8FA71E62AE0A537FAB962F8A2BD1053964C4299DCA 92BFFF4DB82E86D3 auid=1000 ses=3 lsm=ipe res=1 errno=0 The above record shows a new policy has been successfully loaded into the kernel with the policy name, version, and hash with the errno=0. AUDIT_IPE_POLICY_LOAD(1422) with error: audit: AUDIT1422 policy_name=? policy_version=? policy_digest=? auid=1000 ses=3 lsm=ipe res=0 errno=-74 The above record shows a policy load failure due to an invalid policy (-EBADMSG). By adding this error field, we ensure that all policy load attempts, whether successful or failed, are logged, providing a comprehensive audit trail for IPE policy management. Signed-off-by: Jasjiv Singh <jasjivsingh@linux.microsoft.com> Signed-off-by: Fan Wu <wufan@kernel.org>
2024-10-17ipe: allow secondary and platform keyrings to install/update policiesLuca Boccassi
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>
2024-10-17ipe: also reject policy updates with the same versionLuca Boccassi
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>
2024-08-20documentation: add IPE documentationDeven Bowers
Add IPE's admin and developer documentation to the kernel tree. Co-developed-by: Fan Wu <wufan@linux.microsoft.com> 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>