fix(userspace): open pidfile with O_NOFOLLOW to prevent symlink TOCTOU#3871
Open
alexmchughdev wants to merge 1 commit intofalcosecurity:masterfrom
Open
fix(userspace): open pidfile with O_NOFOLLOW to prevent symlink TOCTOU#3871alexmchughdev wants to merge 1 commit intofalcosecurity:masterfrom
alexmchughdev wants to merge 1 commit intofalcosecurity:masterfrom
Conversation
Contributor
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: alexmchughdev The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Contributor
|
Welcome @alexmchughdev! It looks like this is your first PR to falcosecurity/falco 🎉 |
Contributor
|
Hey @alexmchughdev , unfortunately this PR breaks windows build. Could you please take a look? https://github.com/falcosecurity/falco/actions/runs/25507407572/job/75014856179?pr=3871 |
ebd2881 to
2045edd
Compare
The pidfile path is operator-controlled and typically lives in a root-owned directory like /var/run, so this is not exploitable in the standard threat model. However, if an operator configures a pidfile path in a directory writable by an unprivileged user, that user could pre-place a symlink to cause Falco (running as root) to overwrite an arbitrary file with the PID on startup. Replace the std::ofstream open with a raw POSIX open() using O_NOFOLLOW | O_CLOEXEC on non-Windows platforms. The open will now fail with ELOOP if the path is a symlink, closing the defence-in-depth gap with no behaviour change for legitimate users. Windows builds retain the original std::ofstream path since O_NOFOLLOW / O_CLOEXEC are not available on the Windows toolchain and the Linux-as-root threat model that motivates the hardening does not apply to Falco's Windows build. Signed-off-by: Alex McHugh <alexanderedwardmchugh@gmail.com>
2045edd to
8fa549c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind bug
What this PR does / why we need it:
Hardens the pidfile open path in
userspace/falco/app/actions/pidfile.cppagainst a symlink TOCTOU. Previously the pidfile was created viastd::ofstream::open(), which has no portableO_NOFOLLOWequivalent. If an operator configures a pidfile path in a directory writable by an unprivileged user, that user could pre-place a symlink and trick a root-running Falco into clobbering an arbitrary file with the PID on startup.The pidfile path is operator-controlled and typically lives in a root-owned directory like
/var/run, so this is not exploitable in the standard threat model — this is a defence-in-depth fix.The change replaces the
std::ofstreamopen with a raw POSIXopen()usingO_WRONLY | O_CREAT | O_TRUNC | O_NOFOLLOW | O_CLOEXECand writes the PID withdprintf. Theopen()will now fail withELOOPif the path is a symlink. Error reporting goes throughfalco_strerror_rmatching the pattern increate_signal_handlers.cpp. Behaviour is unchanged for legitimate users.Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
exit(-1)on failure as before.O_CLOEXECflag is also added so the fd does not leak into any later forked program-output children.O_NOFOLLOWis there so it is not removed during a future cleanup.Does this PR introduce a user-facing change?: