coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kaz Kylheku (Coreutils)
Subject: Re: cp, ln, mv, install: check for vulnerable target directories
Date: Thu, 21 Sep 2017 12:41:31 -0700
User-agent: Roundcube Webmail/0.9.2

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]