The Quest to Secure chown and symlinks
buildkite.com
The Quest to Secure chown and symlinks
1–10 of 29 posts
Re: The Quest to Secure chown and symlinks
#2test -L checks if a file is a symlink; no need for realpath comparisons (which is slower)
Re: The Quest to Secure chown and symlinks
#3There would traditionally been another TOCTOU is the described solution, namely hardlinks. This can often be used to get root to do something to a file it shouldn't.
The trad solution is to have user writeable areas (home, vartmp, tmp) on different volumes. Some tools have options to not traverse symlinks across volumes for this and other reasons. But on modern systems you are protected by the fs.protected_hardlinks setting.
Re: The Quest to Secure chown and symlinks
#4 (cd "$path" && [ "$(pwd -P)" = "$path" ] && chown -R buildkite-agent:buildkite-agent .)
Re: The Quest to Secure chown and symlinks
#5Why do the files have bad permissions to start with?
Re: The Quest to Secure chown and symlinks
#6I have a small project in this approximate area:
https://www.kylheku.com/cgit/safepath/about/
safepath is a function which tries to analyze whether a path is safe to use. Roughly that means that it doesn't resolve in some way that can be controlled by another (non-root) user.
A something similar to this is in TXR Lisp under the name path-components-safe:
https://www.kylheku.com/cgit/txr/tree/stdlib/path-test.tl?hl...
Re: The Quest to Secure chown and symlinks
#7why is it running as root anyway?
should probably setuid to the correct user and do the thing there instead
Re: The Quest to Secure chown and symlinks
#8There would traditionally been another TOCTOU is the described solution, namely hardlinks. This can often be used to get root to do something to a file it shouldn't. The trad solution is to have user writeable areas (home, vartmp, tmp) on different volumes. Some tools have options to not traverse symlinks across volumes for this and other reasons. But on modern systems you are protected by the fs.protected_hardlinks…
Can a user make a hard link to a file they don't own? How does this attack work?
Re: The Quest to Secure chown and symlinks
#9There would traditionally been another TOCTOU is the described solution, namely hardlinks. This can often be used to get root to do something to a file it shouldn't. The trad solution is to have user writeable areas (home, vartmp, tmp) on different volumes. Some tools have options to not traverse symlinks across volumes for this and other reasons. But on modern systems you are protected by the fs.protected_hardlinks…
Researching this, found [1]:
> POSIX guarantees that hard links can exist. It follows that, on POSIX systems without any non-standard protections, it's unsafe for anyone (but in particular, root) to do anything sensitive in a directory that is writable by another user. Cross-platform programs designed to do so are simply flawed.
I feel like something had to have been lost in translation from Unix to POSIX here. In the original implementation, were users able to hardlink (well, "link") files owned by others? If so, this is a foundational flaw that should probably be fixed across the board with something similar to Linux's non-standard sysctl option.
[1]: http://michael.orlitzky.com/articles/posix_hardlink_heartach...
Re: The Quest to Secure chown and symlinks
#10There would traditionally been another TOCTOU is the described solution, namely hardlinks. This can often be used to get root to do something to a file it shouldn't. The trad solution is to have user writeable areas (home, vartmp, tmp) on different volumes. Some tools have options to not traverse symlinks across volumes for this and other reasons. But on modern systems you are protected by the fs.protected_hardlinks…
Can a user make a hard link to a file they don't own? How does this attack work?
These links (pun unfortunate) should help:
https://sysctl-explorer.net/fs/protected_hardlinks/
http://michael.orlitzky.com/articles/posix_hardlink_heartach...