/proc and directory permissions [LWN.net]

/proc and directory permissions

Posted Oct 29, 2009 4:59 UTC (Thu) by jimparis (subscriber, #38647)
In reply to: /proc and directory permissions by jimparis
Parent article: /proc and directory permissions

Here is an example that shows the non-obvious behavior:

$ 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 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

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

(Log in to post comments)

/proc and directory permissions

Posted Oct 30, 2009 0:33 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

There's something missing from the explanation of why this is a problem, because the basic idea that you can open a file before permissions to it are supposedly revoked and then keep using the file doesn't require any /proc/PID/fd magic.

The scenarios show an attacker opening read-only and then escalating to read-write after some permissions were changed, but the attacker could just as easily have opened read-write in the first place.

Are we supposed to imagine some scenario in which the system administrator ensures only read-only opens have happened at the time he changes the directory permission and thus assumes the file is safe from writing?

/proc and directory permissions

Posted Oct 30, 2009 3:26 UTC (Fri) by jimparis (subscriber, #38647) [Link]

> The scenarios show an attacker opening read-only and then escalating to
> read-write after some permissions were changed

No it didn't. No permissions were changed between the time the attacker had a read-only fd and when the attacker managed to get a read-write fd.

- The attacker could not open the file (neither read-only nor read-write)
- The superuser gave the attacker a read-only handle to the file
- The attacker turned it into a read-write handle

No permissions changes were involved, this is not a race condition.