On Tue 17-01-23 16:14:04, Richard Guy Briggs wrote: > The Fanotify API can be used for access control by requesting permission > event notification. The user space tooling that uses it may have a > complicated policy that inherently contains additional context for the > decision. If this information were available in the audit trail, policy > writers can close the loop on debugging policy. Also, if this additional > information were available, it would enable the creation of tools that > can suggest changes to the policy similar to how audit2allow can help > refine labeled security. > > This patchset defines a new flag (FAN_INFO) and new extensions that > define additional information which are appended after the response > structure returned from user space on a permission event. The appended > information is organized with headers containing a type and size that > can be delegated to interested subsystems. One new information type is > defined to audit the triggering rule number. > > A newer kernel will work with an older userspace and an older kernel > will behave as expected and reject a newer userspace, leaving it up to > the newer userspace to test appropriately and adapt as necessary. This > is done by providing a a fully-formed FAN_INFO extension but setting the > fd to FAN_NOFD. On a capable kernel, it will succeed but issue no audit > record, whereas on an older kernel it will fail. > > The audit function was updated to log the additional information in the > AUDIT_FANOTIFY record. The following are examples of the new record > format: > type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3137 subj_trust=3 obj_trust=5 > type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F subj_trust=? obj_trust=? Everything looks fine to me in this patchset so once patch 3/3 gets ack from audit guys, I'll merge the series to my tree. Thanks for your work! Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
