Jim,

Sorry, but your 'prove' below is wrong!

You are opening the locked down file as root and passing that
fd as input to the nobody process.

So nobody is not opening /dir/file.txt (he can't because he hasn't
access to it via /dir) but root is...
Therefor the write to the fd is failing, because you're passing a
read-only file descriptor.

Try to replay your scenario in separate shells, without the use of
sudo and redirection.

Best regards,
Marco

On 29 okt 2009, at 21:10, Jim Paris wrote:

>>> 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
> safe
>
> 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
> safe
>
> 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
> safe
>
> 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
> hacked
>
> 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.
>
> -jim

[ reply ]