I noticed a problem with chown.c (when CHOWN_MODIFIES_SYMLINK) and chmod-safer.c. If the file being chmod'ed or chown'ed is a special file, opening it can cause undesirable side effects. For example, it might cause a tape drive to be rewound.
Also, the current implementations of mkdir, mkfifo, and mknod arrange for files to be temporarily readable to the owner, even when the requested mode is that the file not be readable to the owner. In the traditional Unix model this doesn't introduce a security-related race condition, since an attacker with owner (or root) privileges can set the file to be readable anyway. But in the ACL world I'm not sure this holds: that is, isn't it possible that granting the owner temporary read permission can cause a real hole? Also, if a directory is temporarily mode 400, that can cause problems with other processes running 'find'. Surely the temporary mode (if we want to continue to use it) should be 400 OR'ed in with the desired mode, not 400. It's not clear to me that these are the only problems with the code; there are some other fairly subtle issues involved, which I don't entirely follow. A bigger issue: it's not clear to me how much safety chmod_safer adds. For example, if /tmp is world-writeable and is not sticky, then "mkdir -m 755 /tmp/a/b" is unsafe even with chmod_safer in place, since the attacker can replace /tmp/a with a symlink. Another example: "mkdir -m 755 /tmp/a" is unsafe if the attacker can rename /tmp/a and rename a victim directory to /tmp/a before mkdir gets around to invoking chmod on what it thinks is the newly created /tmp/a. I suspect that users who share world-writeable directories with untrusted users are fundamentally at risk, and that we cannot fix coreutils to be "secure" in that situation. If so, perhaps we shouldn't bother to try, if trying causes problems in other areas. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
