selinux: migrate to pathrs-lite procfs API

[cyphar]

The previous isProcHandle approach introduced in 03b517d ("selinux:
verify that writes to /proc/... are on procfs") was a fairly naive
solution to CVE-2019-16884 style bugs, as it only checked that the
target was a procfs file without any verification what exact procfs file
it is.

A far more insidious attack (as discussed at the time) would be to
instead bind-mount something like /proc/self/sched on top of
/proc/self/attr/... which would not be detectable using a simple
filesystem type check.

The new pathrs-lite API (provided by filepath-securejoin) can correctly
detect this and includes many other hardenings to avoid attacks of this
kind.

Fixes: CVE-2025-52881
Signed-off-by: Aleksa Sarai [email protected]

[kolyshkin]

Minor doc nits, otherwise lgtm

[dduzgun-security]

👋, thank you for your work on resolving the issue. To safeguard users relying on this library, would it be feasible to release a patched version prior to any public CVE disclosure in the future please? I think it would reduce scanner alerts (+ pipeline failures) on vulnerabilities with no fixed version and eliminate malicious actors trying to exploit this publicly known vulnerability to cause harm.

[cyphar]

@dduzgun-security We (runc) don't have access to push code to this repo unilaterally. I provided @rhatdan with the patches for this issue a month ago and he was given access to the still-embargoed advisories at the time.

(Unfortunately, due to the way Go modules work it would've been necessary for us to do the third_party thing we did in runc regardless of whether we could've co-ordinated a release.)

[dduzgun-security]

@cyphar Thanks for the context. I agree, coordination between teams and contributors are really important in situations like this. From a consumer perspective of the library, having a fixed version released before the vulnerability being available in the vulnerability databases would’ve made it easier to take action quickly and update.

[cyphar]

I would've preferred that too, but we couldn't pick a later disclosure date (KubeCon is this coming week and I am giving a talk about these security issues at a conference in early December).

Given how often security issues with opencontainers/selinux and runc overlap, perhaps we need to come up with a way that runc maintainers can either do a security release on behalf of opencontainers/selinux or we add more runc maintainers to the set of opencontainers/selinux maintainers (@kolyshkin is a maintainer but I don't know if he has the authority to do releases unilaterally -- @mrunalp and @thaJeztah are also runc maintainers but they weren't involved in this security issue and so might not have been able to help).

@rhatdan What do you think?

[rhatdan]

I am fine with adding other maintainers and owners to this Repository. Planning on Retiring in two weeks or so and taking a big step back.

[rhatdan]

@kolyshkin @thaJeztah and @giuseppe all have admin access to this REPO, @cyphar I have giving you Maintain.