I'm wondering why it's not enough to have the native auditing
just to happen.
E.g. all (I have checked RECVMSG,SENDMSG,SEND and CONNECT) socket related io_uring
opcodes
already go via security_socket_{recvmsg,sendmsg,connect}()
IORING_OP_OPENAT* goes via do_filp_open() which is in common with the open[at[2]]()
syscalls
and should also trigger audit_inode() and security_file_open().
So why is there anything special needed for io_uring (now that the native worker threads
are used)?
Is there really any io_uring opcode that bypasses the security checks the corresponding
native syscall
would do? If so, I think that should just be fixed...
stefan's points crossed my mind as well.
but assuming iouring buy-in is required, from a design perspective,
rather than inserting these audit conditionals in the hotpath,
wouldn't a layering model work better?
aka enabling auditing changes the function entry point into io_uring
and passes operations through an auditing layer, then back to the main
entry point. then there is no
cost to audit disabled code, and you just force audit to pay whatever
double processing cost that entails.
V