On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
|| User1 creates file with permissions 0644
|| User2 opens file for read access on file descriptor 4
|| User1 chmod's directory to 0700
|| User1 chmod's file to 0666
|| User1 verifies no hard links to file
|| User2 can not open the file for read or write access
|| User2 can not write to file descriptor 4
|| User2 _can_ write to /proc/$$/fd/4
||
|| Now user2 is expected to be able to have read-access to the file via
|| (he opened it in step 2). If he attempts to write with ">&4" then it
|| silently fails (on Linux, anyway). But access via /proc/$$/fd/4 allows
|| write access.
On Sat, Oct 24, 2009 at 01:46:17AM -0500, Derek Martin wrote:
|| That said, the user in the example already has access to the file (in
|| a running process), and would be able to do so again, *if he had
|| access to a directory where the file was hard-linked*. Pavel
|| described that the sysadmin checked for that, but even if this worked
|| as expected, there's a race condition where the user could create the
|| hard link after the sysadmin checked, but before the permissions were
|| corrected. Unlikely, I know... but possible.
That race is easily fixed. After chmodding the directory to 0700, *first*
check the link count, *then* chmod the file to 0666:
User1 creates file with permissions 0644
User2 opens file for read access on file descriptor 4
User1 chmod's directory to 0700
User1 verifies no hard links to file
User1 chmod's file to 0666
User2 can not open the file for read or write access
User2 can not write to file descriptor 4
User2 _can_ write to /proc/$$/fd/4
Excluding the /proc route, at no point during this sequence, User2 could
have opened the file for writing. Therefore, User1 expects (justified,
imo) that User2 cannot write to the file. The writability of /proc/$$/fd/4
violates this expectation.
It is obscure, because it requires User1 to go through an unusual sequence
of steps, but not inconceivable.
|| I don't think what Pavel described is a very serious hole, but it *IS*
|| a hole, because:
||
|| 1. It circumvents the fact that to write to a file, you MUST be able
|| to write to its directory, so that the file attributes can be updated.
|| That's an important part of accountability.
As already remarked, this is not true. Write access to the directory is
necessary for creating and deleting the file (which changes the contents
of the directory), but not for writing to the file.
In fact, not even read access on the directory is necessary. Traverse (x)
access on the directory is enough to get to the file (inode, actually);
after that, the file permissions determine what you can do to the file's
contents.
Ciao. Vincent.
--
Vincent Zweije <zweije (at) xs4all (dot) nl [email concealed]> | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/> | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] | -- Paul Tomblin on a.s.r.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
|| User1 creates file with permissions 0644
|| User2 opens file for read access on file descriptor 4
|| User1 chmod's directory to 0700
|| User1 chmod's file to 0666
|| User1 verifies no hard links to file
|| User2 can not open the file for read or write access
|| User2 can not write to file descriptor 4
|| User2 _can_ write to /proc/$$/fd/4
||
|| Now user2 is expected to be able to have read-access to the file via
|| (he opened it in step 2). If he attempts to write with ">&4" then it
|| silently fails (on Linux, anyway). But access via /proc/$$/fd/4 allows
|| write access.
On Sat, Oct 24, 2009 at 01:46:17AM -0500, Derek Martin wrote:
|| That said, the user in the example already has access to the file (in
|| a running process), and would be able to do so again, *if he had
|| access to a directory where the file was hard-linked*. Pavel
|| described that the sysadmin checked for that, but even if this worked
|| as expected, there's a race condition where the user could create the
|| hard link after the sysadmin checked, but before the permissions were
|| corrected. Unlikely, I know... but possible.
That race is easily fixed. After chmodding the directory to 0700, *first*
check the link count, *then* chmod the file to 0666:
User1 creates file with permissions 0644
User2 opens file for read access on file descriptor 4
User1 chmod's directory to 0700
User1 verifies no hard links to file
User1 chmod's file to 0666
User2 can not open the file for read or write access
User2 can not write to file descriptor 4
User2 _can_ write to /proc/$$/fd/4
Excluding the /proc route, at no point during this sequence, User2 could
have opened the file for writing. Therefore, User1 expects (justified,
imo) that User2 cannot write to the file. The writability of /proc/$$/fd/4
violates this expectation.
It is obscure, because it requires User1 to go through an unusual sequence
of steps, but not inconceivable.
|| I don't think what Pavel described is a very serious hole, but it *IS*
|| a hole, because:
||
|| 1. It circumvents the fact that to write to a file, you MUST be able
|| to write to its directory, so that the file attributes can be updated.
|| That's an important part of accountability.
As already remarked, this is not true. Write access to the directory is
necessary for creating and deleting the file (which changes the contents
of the directory), but not for writing to the file.
In fact, not even read access on the directory is necessary. Traverse (x)
access on the directory is enough to get to the file (inode, actually);
after that, the file permissions determine what you can do to the file's
contents.
Ciao. Vincent.
--
Vincent Zweije <zweije (at) xs4all (dot) nl [email concealed]> | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/> | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] | -- Paul Tomblin on a.s.r.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iD8DBQFK5tOhr5thWunKoTMRAo4OAKCZcj6zh3gTbUFpWXZHwAI3Dn2vjACfQT2F
km+xlic94K7gDyvuSROpv9w=
=ZyAm
-----END PGP SIGNATURE-----
[ reply ]