On 2023-09-17 20:28:49, Alexe Stefan wrote:
>
> There are 2 open pr's on the opentmpfiles github. One removes the
> security vulnerability, but is non-compliant with the spec, the other
> is (at least is a start of) a rewrite in c.
The PR is still vulnerable. These checks,
_chown() {
local path=$2 uid=$1
if ! owned_by_root "${path}" ; then
...
are insufficient to fix the vulnerability, because it's the parent
path(s) that are the problem. If any parent path is writable by a
non-root user, that non-root user can swap it out from under you,
even if the thing you're operating on is root:root.
AFAIK it's impossible to fix that in shell. In C, you can do a little
openat() dance ensuring that each component of your path is safe from
the root upwards -- that's why one of the suggestions is to rewrite
opentmpfiles in C.
> >As a result, opentmpfiles never should have tried to implement it, but
> >its authors didn't know about those problems either. And while
> >implementing tmpfiles in C has certain unavoidable race conditions,
> >hooooooooo boy is the shell version swiss cheese. There's no safe way
> >to run chown and chmod (the shell commands) as root in a directory you
> >don't control, and that's a big part of what opentmpfiles does. The
> >exploits for the shell version are kindergaren stuff.
>
> Is it really so easy to exploit it?
> How would you do that?
>
The daemon runs "ln" or "ln -s", basically at its leisure, and
waits for opentmpfiles to run again.
