[apparmor] AppArmor io_uring: uring_sqpoll implemented but uring_cmd is missing

[John Johansen]

On 3/15/26 22:48, Sang-Hoon Choi wrote:
> Hi John,
> 
> I noticed that AppArmor implements two of the three io_uring LSM
> hooks but not the third:
> 
>    security_uring_sqpoll       -> apparmor_uring_sqpoll       (implemented)
>    security_uring_override_creds -> apparmor_uring_override_creds
> (implemented)
>    security_uring_cmd          -> (not implemented)
> 
> SELinux implements all three, including uring_cmd (selinux_uring_cmd,
> added August 2022).
> 
correct

> The missing uring_cmd hook means that URING_CMD operations (used by
> ublk, NVMe passthrough, and the upcoming fuse-io-uring) are not
> mediated by AppArmor. On Ubuntu/Debian systems, these operations go
> through with no LSM check at all.
> 
sadly yes

> I ran into this while testing ublk in container environments. A
> privileged container can create block devices via URING_CMD on
> /dev/ublk-control, and AppArmor profiles that restrict device access
> do not cover URING_CMD operations on already-open file descriptors.
> 
correct

> For context, I previously discussed the SQPOLL credential caching
> behavior with Jens Axboe, who confirmed it is by design and pointed
> to the LSM hooks as the correct enforcement point. Since AppArmor
yeah, I am not fond of the credential caching behavior

> already handles sqpoll and credential override, adding uring_cmd
> seems like a natural extension.
> 
yes, it is coming, it is just a matter of dev time.

> Is there a reason uring_cmd was left out when the other two hooks
> were added, or is this just something that hasn't been gotten to yet?
> 

the initial implementation ran into problems with uring_cmd, so
instead of delaying all uring mediation, it was split from sqpoll
and override_creds.

> I am writing a paper analyzing ublk security in containers and want
> to accurately describe AppArmor's coverage. Any information about
> plans for uring_cmd support would help me get the paper right.
> 

yes. Support for uring_cmd is coming as well as uring_allowed. The
issue really is just developer time. Landing new mediation requires
not only the mediation, but also tests, and tooling etc.

There is a lot happening in apparmor atm, with a lot of competing
priorities. The single biggest push atm, has been to fix bugs,
and performance issues, and dramatically expand the CI. This will
put us in a better place to ensure we aren't causing regressions
as we land new mediation.

And there is a bunch of improvements to mediation coming,
including better uring, network, namespace, task, rlimits, object
delegation, identify delegation, and more.








> Thanks.
> 
> Best regards
> Sang-Hoon Choi
>