Re: [PATCH] SELinux: Dontaudit access to dri devices

On 02/04/2026 14:24, Paul Holzinger wrote:

Hi,

On 31/03/2026 21:47, Stefano Brivio wrote:

...

On Tue, 31 Mar 2026 09:00:47 +0200 Johannes Segitz wrote:

...

Hi,

On Mon, Mar 30, 2026 at 05:15:42PM +0200, Stefano Brivio wrote:

...

On Mon, 30 Mar 2026 13:05:57 +0200 Johannes Segitz wrote:

...

Currently podman can pass a FD to a DRI device to pasta, leading to AVCs like this: avc:  denied  { read write } comm="pasta" path="/dev/dri/renderD128" scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file These are harmless, so dontaudit them

Signed-off-by: Johannes Segitz Thanks for the patch.

I'm wondering how can this still happen though, as commit 09603cab28f9 ("passt, util: Close any open file that the parent might have leaked") should take care of those. Do you happen to know? No, I just read the code and it seems like this should prevent this. I unfortunately can't debug this in depth, because it doesn't happen on my system. The reporter is helpful with debugging, but going into gdb sessions with remote hands doesn't sound feasible ;) Yeah, I see. :) ...I finally had a quick look at it.

I think it's actually good that SELinux caught this, because *maybe* we just call close_range() too late and things would be fine otherwise, but if not, we would leave pasta running with access to an unrelated device, which isn't great, even though we don't run as root so it's unlikely we could really do something with it.

By the way I wonder if it's similar to this report:

   https://bugzilla.redhat.com/show_bug.cgi?id=2374197

which I never really tried to figure out.

I described here I think: https://bugzilla.redhat.com/show_bug.cgi?id=2374291#c10

There is never time to close fds earlier, it validates sometime during execve(). My guess because that is the point where it transitions into the pasta_t context so it checks all files against the new policy?

So any leak warnings are impossible to avoid on the pasta side and must be fixed where we leak them.

Johannes it would be good if you can find out where that files gets opened? Is it Podman? The go runtime uses O_CLOEXEC but we do have some manual open calls where we might forget it and as such leaks, it would be good to find and fix them. It would be good if you have a reproducer.

I did a quick spot check in Podman and found a few places where a fd might be leaked: https://github.com/containers/podman/pull/28434 That said I do not think any of these would explain an open /dev/dri path. -- Paul Holzinger