SELinux and the Desktop

[Stephen Smalley]

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 at epoch.ncsc.mil>
National Security Agency