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

[Kaz Kylheku (Coreutils)]

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).

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:

* an attempt to move an existing symlink into a directory where the
  caller has write permission only via S_IWOTH. (The rename system call
  has to check and enforce this).

* an attempt to duplicate a symlink into a directory via hard linking.
  (The link system call has to check and enforce).

* any other situation: overlaid directories? (In consideration of 
whether
  a malicious symlink could be perpetrated in situations in which
  a shared directory is formed by overlaying via unionfs, overlayfs
  and their ilk, and the attacker is able to create symlinks in some of
  the underlying directories even though such an attempt is blocked in
  the assembled directory.)