On Thu, Mar 2, 2023 at 2:05 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Tue, Jan 31, 2023 at 12:11 PM Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > > On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote: ... > > > audit: MAC_POLICY_LOAD policy_name="dmverity_roothash" > > > policy_version=0.0.0 sha256=DC67AC19E05894EFB3170A8E55DE529794E248C2 > > > auid=4294967295 ses=4294967295 lsm=ipe res=1 > > > > The MAC_POLICY_LOAD record type simply states the lsm that had it's policy > > loaded. There isn't name, version, and hash information. I'd prefer to see > > all users of this record type decide if it should be extended because they > > also have that information available to record. > > Not all LSMs which load policy have that information; as an example, > SELinux doesn't have the concept of a policy name or version. The > SELinux policy version you might see in the kernel sources refers to > the policy format version and has no bearing on the actual policy > content beyond that dictated by the format. > > If additional information is required by IPE, perhaps an auxiliary IPE > policy load record could be created with those additional fields. The issue of policy load audit records came up in an offline discussion with Fan today and I think it's worth talking about this a bit more to reach some consensus. Currently only SELinux generates MAC_POLICY_LOAD records, and it contains all of the information that is present in the IPE example above with the exception of the 'policy_name', 'policy_version', and the policy digest. I personally don't have a problem extending the MAC_POLICY_LOAD record with these fields, and leaving them unused/"?" in the SELinux generated records. It's possible we may even want to use the policy digest field at some point, as it would be nice to be able to have some policy "key" within SELinux that could be used to help identify the loaded policy. The only catch is that we may want to find a better field name than just 'sha256', in the context of the MAC_POLICY_LOAD record it seems easily understood, but in the larger context of a full audit stream it might be too ambiguous. We would also need to decide if we wanted to encode the digest algorithm in the field name, the field value, or have it as a separate field. I might lean towards encoding it in the field value like this: policy_digest=sha256:XXXXX ... however that is something that would need some discussion from the other folks on the To/CC line. -- paul-moore.com -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
