![[BACK]](/icons/back.gif){kind=icon}
Up to [local] / src / usr.bin / users
Request diff between arbitrary revisions
Default branch: MAIN
Current tag: OPENBSD_6_5
Revision 1.14 / (download) - annotate - [select for diffs], Fri Aug 3 16:02:53 2018 UTC (5 years, 10 months ago) by deraadt
Branch: MAIN
CVS Tags: OPENBSD_6_9_BASE,
OPENBSD_6_9,
OPENBSD_6_8_BASE,
OPENBSD_6_8,
OPENBSD_6_7_BASE,
OPENBSD_6_7,
OPENBSD_6_6_BASE,
OPENBSD_6_6,
OPENBSD_6_5_BASE,
OPENBSD_6_5,
OPENBSD_6_4_BASE,
OPENBSD_6_4
Changes since 1.13: +3 -1 lines
Diff to previous 1.13 (colored)
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.