On Thu, 2 Apr 2026 14:24:49 +0200
Paul Holzinger
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