Re: [RFC PATCH 4/9] audit: add filtering for io_uring records

On 2021-05-21 17:50, Paul Moore wrote: Is this necessary? auditd and auditctl don't (intentionally) use any io_uring functionality. Is it possible it might inadvertantly use some by virtue of libc or other library calls now or in the future? While this seems like the most obvious approach given the parallels between syscalls and io_uring operations, as coded here it won't work due to the different mappings of syscall numbers and io_uring operations unless we re-use the auditctl -S field with raw io_uring operation numbers in the place of syscall numbers. This should have been obvious to me when I first looked at this patch. It became obvious when I started looking at the userspace auditctl.c. The easy first step would be to use something like this: auditctl -a uring,always -S 18,28 -F key=uring_open to monitor file open commands only. The same is not yet possible for the perm field, but there are so few io_uring ops at this point compared with syscalls that it might be manageable. The arch is irrelevant since io_uring operation numbers are identical across all hardware as far as I can tell. Most of the rest of the fields should make sense if they do for a syscall rule. Here's a sample of userspace code to support this patch: https://github.com/rgbriggs/audit-userspace/commit/a77baa1651b7ad841a220e... https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:... If we abuse the syscall infrastructure at first, we'd need a transition plan to coordinate user and kernel switchover to seperate mechanisms for the two to work together if the need should arise to have both syscall and uring filters in the same rule. I'm still exploring ideas on the best place to put this translation table, in userspace libaudit, kaudit, io_op_defs[], include/uapi/linux/io_uring.h, ... For speed, the best would be in userspace libaudit, but that will be the least obvious place for any io_uring developer to look when making any updates to the list of io_uring operations and will most likely result in additions escaping security logging. Next best for speed would be in kaudit when instantiating rules, to translate the syscall numbers to operation numbers and store them natively in a different mask (audit_in_mask). This also runs the risk of additions escaping security logging. After that, they could reuse the existing audit syscall filter infrastructure and mask and translate on the fly from the specific op in use to its equivalent syscall number when checking the existing filter. This is the least disruptive to the audit code and the most likely to be updated when new io_uring operations are added, but will incur an extra step to translate the io_uring operation number to a syscall number in the hot path. Given that multiple aspects of security appear to have been a complete afterthought to this feature, necessitating it to be bolted on after the fact, it appears that the last option might be the most attractive to the security folks, making this as easy as possible for fs folks to update the audit code would be necessary to maintain security. If there isn't a direct mapping between io_uring operations and syscalls (the reverse isn't needed), then we'll need to duplicate the mechanism throughout the stack starting in userspace auditctl and libaudit. Currently the bitmap for syscalls is 2k. The current io_uring op list appears to be 37. It might be wise to deliberately not support auditctl "-w" (and the exported audit_add_watch() function) since that is currently hardcoded to the AUDIT_FILTER_EXIT list and is the old watch form [replaced by audit_rule_fieldpair_data()] anyways that is more likely to be deprecated. It also appears to make sense not to support autrace (at least initially). Does any of this roughly make sense? - RGB -- Richard Guy Briggs <rgb(a)redhat.com&gt; Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635