unveil _PATH_UTMP at startup. Time for a commentary:

There is a TOCTOU between unveil() and open() which should always be
considered, since a path is being supplied twice to the kernel.  First
unveil()s define which paths remain in scope, then secondly open()s
try to access paths in scope.  The unveil() generates a vnode
reservation against the final path resolution (including symbolic link
collapse).  Before the open() occurs, root could replace the path with
symbolic traversal pointing elsewhere.  Then open() will traverse a
path which fails to discover the reserved vnode, and thus fail with
ENOENT.  The TOCTOU sequence doesn't succeed against the new path, it
*always fails*.  (Unless the symlink resolves to another unveil'd
vnode object, but that is not new behaviour).

So once a process is running with veiled filesystem view, we can
consider such a symlink change action as PERMANENTLY visible to this
process and correctly contained to the scoped view, rather than the
previous behaviour of being TRANSIENT and global in view.  So this is
not a real race, security implications will be narrow, and generally
the old symlink-race case is the less secure.

When we add this unveil+open TOCTOU scenario to a program, we should
consider who can perform such a symlink snap, and whether behaviour
change to the program is more disruptive than the risks prevented
through filesystem hiding.  How does a program behave if a file
disappears due to active interference?  Are users (and scripts) used
to operating in a racey best-effort way, and is the additional
strictness strangling their freedom to run shitty stuff?

A few general rules for base programs can avoid problems in this area:
don't en masse unveil argv[], then process argv[] in a second phase.
Don't unveil args which get placed into TZ, TERM, and some other
environment variables, unless you completely understand what libc is
doing.

0 files changed, 0 insertions, 0 deletions