/proc and directory permissions [LWN.net]

/proc and directory permissions

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

It's not as bad as you thought -- setting up the right situation is tricky.

Consider something like this setup:

$ sudo 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    6 2009-10-29 00:28 file.txt

Now as an unprivileged user, you can't read or write the file, even though it's mode 0666, because the directory is mode 0700:

$ echo hi > /dir/file.txt
bash: /dir/file.txt: Permission denied

Now here's the trick. Assume that you somehow have an open read-only file descriptor that refers to this file. In the bugtraq conversations, this was achieved by opening the file while the administrator was messing with permissions. But there are other cases — for example, a system daemon might have opened the file read-only and passed you the file descriptor over Unix sockets. Or you inherited a read-only file descriptor when your process was started.

Now, once you have this open fd, you can re-open it as read-write using the link in /proc/$YOUR_OWN_PID/fd/ — which is allowed because the file is mode 0666, even though the directory typically wouldn't allow you to do that.

A source of contention is whether this is unexpected. It's certainly not completely obvious.

(Log in to post comments)

/proc and directory permissions

Posted Oct 29, 2009 4:59 UTC (Thu) by jimparis (subscriber, #38647) [Link]

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

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