Re: [PATCH v3] ipe: add errno field to IPE policy load auditing
From: Fan Wu
Date: Wed Mar 05 2025 - 16:23:45 EST
On Tue, Mar 4, 2025 at 4:04 PM Jasjiv Singh
<jasjivsingh@xxxxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 3/3/2025 2:11 PM, Fan Wu wrote:
> > On Fri, Feb 28, 2025 at 3:11 PM Jasjiv Singh
> > <jasjivsingh@xxxxxxxxxxxxxxxxxxx> wrote:
> >>
> >> 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:
> >>
> >> * 0: no error
> >> * -EPERM: Insufficient permission
> >> * -EEXIST: Same name policy already deployed
> >> * -EBADMSG: policy is invalid
> >> * -ENOMEM: out of memory (OOM)
> >> * -ERANGE: policy version number overflow
> >> * -EINVAL: policy version parsing error
> >>
> >
> > These error codes are not exhaustive. We recently introduced the
> > secondary keyring and platform keyring to sign policy so the policy
> > loading could return -ENOKEY or -EKEYREJECT. And also the update
> > policy can return -ESTALE when the policy version is old.
> > This is my fault that I forgot we should also update the documentation
> > of the newly introduced error codes. Could you please go through the
> > whole loading code and find all possible error codes? Also this is a
> > good chance to update the current stale function documents.
> >
> > ...
> >
>
> So, I looked into error codes when the policy loads. In ipe_new_policy,
> the verify_pkcs7_signature can return a lot of errno codes (ex: ENOKEY,
> EKEYREJECTED, EBADMSG, etc.) while parsing the pkcs7 and other functions
> as well. Also, In ipe_new_policyfs_node used in new_policy(), I see the same
> issue with securityfs_create_dir and securityfs_create_file as they
> return the errno directly from API to. So, what should we return?
I think the key here is we need to document the errors in the ipe's
context. For example, ENOKEY means the key used to sign the ipe policy
is not found in the keyring, EKEYREJECTED means ipe signature
verification failed. If an error does not have specific meaning for
ipe then probably we don't need to document it.
>
> For other functions: I have complied the errno list:
>
> * -ENOENT: Policy is not found while updating
This one means policy was deleted while updating, this only happens
the update happened just after the policy deletion.
> * -EEXIST: Same name policy already deployed
> * -ERANGE: Policy version number overflow
> * -EINVAL: Policy version parsing error
> * -EPERM: Insufficient permission
> * -ESTALE: Policy version is old
Maybe make this one clearer, how about trying to update an ipe policy
with an older version policy.
-Fan