4 ms·
My objection would be that one (or more) path component(s) could come under the control of an adversary in between the check and the use. Granted it might take
by Quekid5 3y ago
My objection would be that one (or more) path component(s) could come under the control of an adversary in between the check and the use. Granted it might take a weird set of circumstances -- e.g. a deployment process running in parallel doing odd things with permissions[0] -- but the fundamental problem seems to be essentially unsolvable without kernel support.
It's definitely a great improvement, though.
[0] Which would arguably be a bug with the other process, but this is the world we live in :/
- kazinator 3y agoRight. Basically the deployment would have to happen in a secret tree: a directory with a hard to guess name (e.g. 256 bit random hex string) in a root-owned directory that is not readable to anyone but root. Only when the deployment is finalized (all chown and chmod operations have been done) is that tree then renamed to its deployment location. Whenever root creates an object owned by root, which is then chown-ed to non-root, if an adversary can point a root process at that object, that could subvert safepath.
- Quekid5 3y agoJust a little thing: Ownership could change from root-to-foo-and-back-again in between Check and Use. We might be talking degenerate cases, again. ... but again^2, probably a huge improvement over ignoring the problem. It will ultimately need OS-API support to avoid these types of issues fully. As an aside: C++'s filesystem API is (very theoretically) largely unusable due to issues like these. Effectively, almost all of it is UB if even a single other process is doing writes on the filesystem you're accessing.