On Thu, Apr 02, 2026 at 03:46:13PM +0200, Stefano Brivio wrote:
On Thu, 2 Apr 2026 14:24:49 +0200 Paul Holzinger
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:
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)