[PATCH] SELinux: Dontaudit access to dri devices

[PATCH] SELinux: Dontaudit access to dri devices

[Johannes Segitz]

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>
---
 contrib/selinux/pasta.te | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/contrib/selinux/pasta.te b/contrib/selinux/pasta.te
index fb51416..4bc7dcc 100644
--- a/contrib/selinux/pasta.te
+++ b/contrib/selinux/pasta.te
@@ -262,3 +262,5 @@ if (pasta_bind_all_ports) {
 	allow pasta_t port_type:tcp_socket { accept getopt name_bind name_connect };
 	allow pasta_t port_type:udp_socket { accept getopt name_bind };
 }
+
+dev_dontaudit_rw_dri(pasta_t)
-- 
2.53.0

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

[Stefano Brivio]

[Adding Paul as he might know why this happens]

Hi Johannes,

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?

Perhaps the access happens before we call isolate_initial()... but then
I guess we should try to close leaked files before that point, to be on
the safe side?

-- 
Stefano

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

[Johannes Segitz]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

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 ;)

> Perhaps the access happens before we call isolate_initial()... but then
> I guess we should try to close leaked files before that point, to be on
> the safe side?

Would be worth a try. If you have a patch for that I can provide an updated
package to the reporter and ask him to test it

Johannes
-- 
GPG Key                EE16 6BCE AD56 E034 BFB3  3ADD 7BF7 29D5 E7C8 1FA0
Subkey fingerprint:    250F 43F5 F7CE 6F1E 9C59  4F95 BC27 DD9D 2CC4 FD66
SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg, Germany
Geschäftsführer: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Stefano Brivio]

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.

> > Perhaps the access happens before we call isolate_initial()... but then
> > I guess we should try to close leaked files before that point, to be on
> > the safe side?  
> 
> Would be worth a try. If you have a patch for that I can provide an updated
> package to the reporter and ask him to test it

Assuming that the kernel version is >= 5.9 (otherwise we don't have
close_range() at all), you could try something like this:

---
diff --git a/passt.c b/passt.c
index f84419c..d5dad4c 100644
--- a/passt.c
+++ b/passt.c
@@ -340,6 +340,8 @@ int main(int argc, char **argv)
 	struct timespec now;
 	struct sigaction sa;
 
+	close_range(STDERR_FILENO + 1, ~0U, CLOSE_RANGE_UNSHARE);
+
 	if (clock_gettime(CLOCK_MONOTONIC, &log_start))
 		die_perror("Failed to get CLOCK_MONOTONIC time");
 
---

and, if it doesn't work, try to close standard error as well (no idea
why a DRI device would be passed as standard error but I'm not sure why
we would have it as any other open file descriptor either):

	close_range(STDERR_FILENO, ~0U, CLOSE_RANGE_UNSHARE);

...all the way to:

	close_range(0, ~0U, CLOSE_RANGE_UNSHARE);

...if that doesn't work, the next thing I would try is to add a delay
in the Podman thread starting pasta (or even there at the beginning
of main() in pasta itself), use that delay to attach with strace (as
root, pasta won't let you do that otherwise), correlate timestamps
with SELinux logs, and from there everything should be clear.

-- 
Stefano

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

[Johannes Segitz]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Tue, Mar 31, 2026 at 09:47:59PM +0200, Stefano Brivio wrote:
> Assuming that the kernel version is >= 5.9 (otherwise we don't have
> close_range() at all), you could try something like this:
> 
> ---
> diff --git a/passt.c b/passt.c
> index f84419c..d5dad4c 100644
> --- a/passt.c
> +++ b/passt.c
> @@ -340,6 +340,8 @@ int main(int argc, char **argv)
>  	struct timespec now;
>  	struct sigaction sa;
>  
> +	close_range(STDERR_FILENO + 1, ~0U, CLOSE_RANGE_UNSHARE);
> +
>  	if (clock_gettime(CLOCK_MONOTONIC, &log_start))
>  		die_perror("Failed to get CLOCK_MONOTONIC time");
>  
> ---

Thanks. I've build an updated package for the reporter and will let you
know once I get feedback from him

Johannes
-- 
GPG Key                EE16 6BCE AD56 E034 BFB3  3ADD 7BF7 29D5 E7C8 1FA0
Subkey fingerprint:    250F 43F5 F7CE 6F1E 9C59  4F95 BC27 DD9D 2CC4 FD66
SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg, Germany
Geschäftsführer: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Paul Holzinger]

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.

>>> Perhaps the access happens before we call isolate_initial()... but then
>>> I guess we should try to close leaked files before that point, to be on
>>> the safe side?
>> Would be worth a try. If you have a patch for that I can provide an updated
>> package to the reporter and ask him to test it
> Assuming that the kernel version is >= 5.9 (otherwise we don't have
> close_range() at all), you could try something like this:
>
> ---
> diff --git a/passt.c b/passt.c
> index f84419c..d5dad4c 100644
> --- a/passt.c
> +++ b/passt.c
> @@ -340,6 +340,8 @@ int main(int argc, char **argv)
>   	struct timespec now;
>   	struct sigaction sa;
>   
> +	close_range(STDERR_FILENO + 1, ~0U, CLOSE_RANGE_UNSHARE);
> +
>   	if (clock_gettime(CLOCK_MONOTONIC, &log_start))
>   		die_perror("Failed to get CLOCK_MONOTONIC time");
>   
> ---
>
> and, if it doesn't work, try to close standard error as well (no idea
> why a DRI device would be passed as standard error but I'm not sure why
> we would have it as any other open file descriptor either):
>
> 	close_range(STDERR_FILENO, ~0U, CLOSE_RANGE_UNSHARE);
>
> ...all the way to:
>
> 	close_range(0, ~0U, CLOSE_RANGE_UNSHARE);
>
> ...if that doesn't work, the next thing I would try is to add a delay
> in the Podman thread starting pasta (or even there at the beginning
> of main() in pasta itself), use that delay to attach with strace (as
> root, pasta won't let you do that otherwise), correlate timestamps
> with SELinux logs, and from there everything should be clear.
>
-- 
Paul Holzinger

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

[Paul Holzinger]

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

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

[Stefano Brivio]

On Thu, 2 Apr 2026 14:24:49 +0200
Paul Holzinger <pholzing@redhat.com> wrote:

> On 31/03/2026 21:47, Stefano Brivio wrote:
>
> [...]
>
> > 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

Gosh, I missed that, thanks.

I wonder how many of these other tickets (especially the ones in NEW)
around SELinux:

  https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&list_id=13663808&namedcmd=passt&sharer_id=410109

might also be caused by that. We would need to triage them at some
point.

> 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?

What's mildly interesting (and what tricked me here) is that in this
case we get { read write }, in some other cases we get "read" or
"append" access only... but I suppose that simply depends on how the
file was opened by the leaking process in the first place.

But I didn't really track this down in the SELinux hooks in the kernel,
so I'd still be a bit curious to see what happens if we close_range()
things right away.

-- 
Stefano

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

[Johannes Segitz]

[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]

On Thu, Apr 02, 2026 at 03:46:13PM +0200, Stefano Brivio wrote:
> On Thu, 2 Apr 2026 14:24:49 +0200
> Paul Holzinger <pholzing@redhat.com> wrote:
> 
> > On 31/03/2026 21:47, Stefano Brivio wrote:
> >
> > [...]
> >
> > > 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
> 
> Gosh, I missed that, thanks.
> 
> I wonder how many of these other tickets (especially the ones in NEW)
> around SELinux:
> 
>   https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&list_id=13663808&namedcmd=passt&sharer_id=410109
> 
> might also be caused by that. We would need to triage them at some
> point.
> 
> > 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?
> 
> What's mildly interesting (and what tricked me here) is that in this
> case we get { read write }, in some other cases we get "read" or
> "append" access only... but I suppose that simply depends on how the
> file was opened by the leaking process in the first place.
> 
> But I didn't really track this down in the SELinux hooks in the kernel,
> so I'd still be a bit curious to see what happens if we close_range()
> things right away.

The first patch version didn't help, now asked the reporter to test the
second version and also patched podman with the change Paul sent upstream.

I unfortunately can't test it myself since it doesn't happen for me, but I
hope to be able to provide the test packages to the reporter before I leave
for easter and will report back next week then

Johannes
-- 
GPG Key                EE16 6BCE AD56 E034 BFB3  3ADD 7BF7 29D5 E7C8 1FA0
Subkey fingerprint:    250F 43F5 F7CE 6F1E 9C59  4F95 BC27 DD9D 2CC4 FD66
SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg, Germany
Geschäftsführer: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]