[PATCH] SELinux: Dontaudit access to dri devices
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
[Adding Paul as he might know why this happens]
Hi Johannes,
On Mon, 30 Mar 2026 13:05:57 +0200
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
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
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 ;)
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)
On Tue, 31 Mar 2026 09:00:47 +0200
Johannes Segitz
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.
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
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)
participants (2)
-
Johannes Segitz
-
Stefano Brivio