On Mon, Sep 23, 2024 at 08:54:03AM -0400, Paul Moore wrote:
> [Sorry for the delay, between flying back home, and just not wanting
> to think about the kernel for a day, I took the weekend "off".]
>
> Jens and I have talked about similar issues in the past, and I think
> the only real solution to ensure the correctness of the audit records
> and provide some consistency between the io_uring approach and
> traditional syscalls, is to introduce a mechanism where we
> create/clone an audit_context in the io_uring prep stage to capture
> things like PATH records, stash that audit_context in the io_kiocb
> struct, and then restore it later when io_uring does/finishes the
> operation. I'm reasonably confident that we don't need to do it for
> all of the io_uring ops, just the !audit_skip case.
>
> I'm always open to ideas, but everything else I can think of is either
> far too op-specific to be maintainable long term, a performance
> nightmare, or just plain wrong with respect to the audit records.
>
> I keep hoping to have some time to code it up properly, but so far
> this year has been an exercise in "I'll just put this fire over here
> with the other fire". Believe it or not, this is at the top of my
> TODO list, perhaps this week I can dedicate some time to this.
What are the requirements regarding the order of audit_names in
the ->names_list? I really don't like the idea of having struct filename
tied to audit_context - io_uring is not the only context where it might
make sense to treat struct filename as first-class citizens.
And having everything that passed through getname()/getname_kernel()
shoved into ->names_list leads to very odd behaviour, especially with
audit_names conversions in audit_inode()/audit_inode_child().
Look at the handling of AUDIT_DEV{MAJOR,MINOR} or AUDIT_OBJ_{UID,GID}
or AUDIT_COMPARE_..._TO_OBJ; should they really apply to audit_names
resulting from copying the symlink body into the kernel? And if they
should be applied to audit_names instance that had never been associated
with any inode, should that depend upon the string in those being
equal to another argument of the same syscall?
I'm going through the kernel/auditsc.c right now, but it's more of
a "document what it does" - I don't have the specs and I certainly
don't remember such details.
