Re: cp, ln, mv, install: check for vulnerable target directories

[Kaz Kylheku (Coreutils)]

On 21.09.2017 11:03, Kaz Kylheku (Coreutils) wrote:
> On 21.09.2017 09:18, Kaz Kylheku (Coreutils) wrote:
> > On 20.09.2017 18:59, Paul Eggert wrote:
> > > Kaz Kylheku (Coreutils) wrote:
> > > > Instead of checking for what *could* go wrong, why not defend more
> > > > specifically against signs that the attack might be actually 
> > > > happening.
> > >
> > > That's what the patch is trying to do, though it looks like it should
> > > be improved.
> >
> > There is a simple operating system fix for this: do not allow 
> > processes
> > to create symlinks in directories to which they only have write 
> > accesses via
> > S_IWOTH.
>
> Two additional notes:
>
> Rather than a hard-coded behavior, this could be a "nolink" mount 
> option,
> somewhat analogous to "nodev" (deny use of device nodes present in the
> filesystem).

I completely missed the full value latent in this analogy.

Just like "nodev" doesn't prevent creation of device nodes with mknod,
but is aimed at curtailing their *use*, the proposed "nolink" mount 
option
could similarly prevent the *traversal* of symlinks created in a shared
directory rather than blocking the means of their creation.

Suppose user mallory creates a symlink in a directory where multiple 
non-root
users have write access. Then have it so that only mallory can follow 
the
symlink (being the owner of the link).

A symlink owned by mallory in a directory that is writable to alice
shall not be dereferenceable by alice; there will be an EPERM when alice
tries to traverse it.

(If the filesystem is mounted "nolink".)

> The permission denial would have to apply, of course, not only when a
> new symlink is created via the symlink system call, but also to:

That takes care of the problem of trying to police various ways
in which a symlink can sneak in. Let the symlink appear by any means,
and just render it inoperable.

The criterion used by "nolink" could be that if a directory is being
traversed and the next path component is a symbolic link found in
that directory, then the traversal is allowed if either:

* the owner of the link and owner of the directory are the same UID; or

* the owner of the link is the same as the effective UID of the caller.

This is applied regardless of the permissions on the directory.
Otherwise the traversal is denied with EPERM. All other existing
considerations for the use of the symlink continue to apply also.

Essentially, a directory in a "nolink" mounted FS has to "vouch for"
a child symlink by having the same security attribute with regard to
ownership, or else the symlink has to be the caller's own item.