Auditing Io_uring

[vp8989]

This reminds me of things like SOX, HIPAA where for any set of compliance/audit requirements there is a layer of people in the middle who always suggest to add all kinds of un-necessary things "just in case" it might be required. These suggestions are based on their interpretation or pre-empting of the compliance process rather than anything that is actually explicitly required.

Why can't the auditors explicitly state what needs to be auditable about io_uring? Instead of guessing and debating.

[duskwuff]

"Auditing", in this context, refers specifically to the kernel audit framework, cf.

https://wiki.archlinux.org/title/Audit_framework

[stefan_]

The killer quote:

> Axboe pointed out that read and write operations are not audited when they are initiated through the older asynchronous I/O system calls. "In the past two decades, I take it that hasn't been a concern?"

And then there are the 20 years of Linux kernel history that show "audit features" being ineffective, wasteful and little more than a checklist feature.

[staticassertion]

> And then there are the 20 years of Linux kernel history that show "audit features" being ineffective, wasteful and little more than a checklist feature.

wuh?? Audit features are used at tons of companies for data collection/ security.

[richardwhiuk]

> He agreed that some operations (such as opening or removing files) should be audited, but said that auditing read and write operations was "just utter noise and not useful at all"

Seems a perfectly sensible half way point - and consistent with other IO mechanisms.

[kingvash]

> The kernel community has surprisingly few rules regarding the addition of new features like io_uring. ... there is nobody with a checklist making sure that all of the relevant boxes have been marked before a new subsystem can be merged.

This is such a stark difference from the big tech company I work at where there are checklists from the security, privacy, performance, and maintenance teams that have to be satisfied before features can be launched.

[otterley]

This seems like one of those things that should be possible to enable by recompiling the kernel, but disabled by default. Tradeoffs are abundant in software features vs. performance, and this isn't really much different. The security-minded user can decide to take the performance hit if they really need to enable auditing. The key is to clearly document how to enable it and to set expectations regarding the performance impact.

[nieve]

I believe audit is already optional at compile time. As the article points out audit being enabled is a requirement for some certifications, so what actually gets shipped by some distros is going to have it on regardless. If say RHEL and Ubuntu enable audit (I believe they do) declaring you've fixed the problems by making sure it's still optional isn't actually addressing it.

[jjav]

The article briefly touches, and dismisses it, but this (and in fact, all of the audit support) seems like a prime candidate for trace points. No overhead cost to anyone except those who want to enable the ones they care about, no custom kernels needed.

These are already being used in many places to monitor/audit execution points not otherwise instrumented, so it's just a logical extension.

[cryptonector]

Auditing every I/O is not really reasonable. If you need that level of auditing, then build it into your applications and build a proper cryptographic audit trail protocol.

[stevemk14ebr]

you want your kernel to do that because it's the source of truth. And what if you want to audit execution that includes binary blobs you don't own the source of?

[kzrdude]

If auditing is so unpopular, it could just be compiled out as a configurable feature?

[tomohawk]

This push from the audit people that they should have been involved from the beginning may have a little merit, but it seems like the real issue is that now that auditing is being added, its obvious what it is doing to the system.

I've worked on systems that have auditing turned on. They usually have to be upsized by quite a bit to accomplish the same work. And the info generated is practically useless.

[stevemk14ebr]

Useless, to you. Having weekend security incident response people with auditing like this we love because their system is actually introspectable

[xiphias2]

If io_uring wouldn't be such a success story, security researchers wouldn't need to worry about it so much. So I guess the order of things happening is not that big of a problem.

[wyldfire]

I don't know if I agree. An attacker may be able to craft a call to io_uring_{setup,enter,etc} even if no call exists in the program under attack. And if io_uring is poorly designed it could result in a privilege escalation or other bad things.

I suppose if it were a completely uninteresting feature it wouldn't end up enabled in most distros' kernel configs.

[mperham]

The subsystem maintainer who merged io_uring dropped the ball. Part of merging any major feature is considering orthogonal concerns like security, logging, etc.

[sjansen]

That's a pretty strong statement considering there was an extended review period before merging and no one expressed any concerns.

Instead of singling out a single person, I think it's more accurate to say the security community in general dropped the ball by not bringing concerns earlier to the maintainer who performed the merge(s).