selinux: migrate to pathrs-lite procfs API#237
Conversation
cyphar
requested review from
kolyshkin,
mrunalp,
rhatdan,
runcom and
thaJeztah
as code owners
cyphar
force-pushed
the
selinux-safe-procfs
branch
2 times, most recently
from
4e08b03 to
b7f1b16
Compare
kolyshkin
left a comment
kolyshkin
left a comment
There was a problem hiding this comment.
Minor doc nits, otherwise lgtm
|
👋, 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. |
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]>
cyphar
force-pushed
the
selinux-safe-procfs
branch
from
b7f1b16 to
c8cfa6f
Compare
|
@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 |
|
@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. |
|
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? |
|
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. |
|
@kolyshkin @thaJeztah and @giuseppe all have admin access to this REPO, @cyphar I have giving you Maintain. |
|
Fix included in accepted release 4.22.0-0.nightly-2026-02-08-124411 |
|
Let me lock this PR, otherwise that @openshift-merge-robot continues spamming with comments (not sure where to report that; I've seen it happening on other repositories) |
7 participants
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]