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.
> 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.
> 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.
This is true! It's also a checklist item that often involves shuffling a lot of bits around, storing them for 60, 90, or 366 days, and then deleting them, and without anyone or anything having read them.
As with many checklist items, it is a useful technology that when set up and followed, can be totally awesome.
Turning on and adding some "proper" filters on the audit subsystem won us the first spot in a CTF, as the early markers that "something is up" turned out to be excellent.
But if all you do with it is pipe it to your log server and ignore it? Well, then it's not really going to help you, and is only a checkbox item.
I feel that much of this disparaging on various "checklist" items is crappy half-assed semi-elitism. Checklists are _amazing_ tools for preventing accidents in many industries, everything from surgery to trains and flight use them with great success.
So why can't information security professionals use them without being derided by others in the business? Perhaps the same reason as doctors insisted that hand washing was time consuming and unnecessary, or the financial institutes that insist that oversight and auditing is unnecessary.
OK but it's also extremely useful and the backbone of almost all incident response on Linux servers... The fact that it's a checklist really isn't relevant - no one is checklisting that specific system calls are instrumented, and that's not even how compliance works.
> 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.
> 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.
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.
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.
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.
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.
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?
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.
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.
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.
Audit logs don't need to be complete to be useful. You can still investigate a wide range of issues in applications that are only (or primarily) using audited APIs. Of course they are more useful if they are complete, but it isn't the only use case.
The subsystem maintainer who merged io_uring dropped the ball. Part of merging any major feature is considering orthogonal concerns like security, logging, etc.
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).
Why can't the auditors explicitly state what needs to be auditable about io_uring? Instead of guessing and debating.