On Thu, 2004-10-14 at 14:51, Colin Walters wrote: > Well, this is only a threat in the case where the caller can do an > unlink in the directory that the script is in, correct? No, because the kernel just passes through the path as provided; it doesn't canonicalize it. So you can use a symlink or hard link in your home directory to the real script, then rewrite that path to refer to something else. > Right now though if you tried to do that a malicious attacker > could set many environment variables like PATH or IFS which shell > scripts would pick up. Cleaning the environment would close that hole. SELinux does enable glibc secure mode upon a domain transition, and glibc does sanitize certain environment variables in that case. So you could possibly add further variables to the list used by glibc to help protect scripts. But that won't resolve the race. I think that Solaris addressed the race by having the kernel open the script file and provide the descriptor to the interpreter, much as Linux already does for the ELF interpreter. Problem with that solution is that userspace expects a path, not a fd, so I think Solaris passes /dev/fd/n as the path. That would seem to almost work, except that /dev/fd/n -> /proc/self/fd/n on Linux becomes inaccessible upon setuid/setgid execution to avoid an information leak. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
