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

[Paul Holzinger <pholzing@redhat.com>]

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 <jsegitz@suse.de> 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 
>>>> <jsegitz@suse.de> 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 <jsegitz@suse.de>
>>>> 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