On 5/26/2021 8:49 AM, Victor Stewart wrote: >> 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. There seems to be an assumption that the audit code isn't concerned about processing cost. This is complete nonsense. While an audit system has to be accurate and complete (hence encompassing io_uring) it also has to be sufficiently performant for the system to be useful when it is enabled. It would have been real handy had the audit and LSM requirements been designed into io_uring. The performance implications could have been addressed up front. Instead it all has to be retrofit. io_uring, Audit and LSM need to perform well and the best way to ensure that the combination works is cooperation between the developers. Any response that includes the word "just" is unlikely to be helpful. > > V > > -- > Linux-audit mailing list > Linux-audit@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/linux-audit >