Re: type transitioning script race condition?

[Klaus Weidner <klaus@atsec.com>]

On Thu, Aug 31, 2006 at 09:53:03AM -0400, Joshua Brindle wrote:
> On Thu, 2006-08-31 at 09:23 -0400, Karl MacMillan wrote:
> > If you write a C program that wrapper both issues should be greatly
> > mitigated because you are no longer gaining privilege on the script
> > execution - see
> > http://svn.python.org/view/python/trunk/Misc/setuid-prog.c?rev=11583&view=auto. I've been meaning to do this for semanage for a while but haven't gotten to it yet.
> 
> The one you referenced is specific to python but I'd like something more
> general, basically what I'm envisioning is a wrapper that you symlink
> all your interpreters to:
> 
> /usr/bin/perl -> /usr/lib/wrapper/envcleaner (or whatever)
> same with python, php, etc
> 
> and when the wrapper is run it looks at how it was run argv[0] and
> checks a config file, something like:
> 
> /usr/bin/python:
> (from the above link)
> bad_vars: LD_* _RLD* PYTHON IFS CDPATH ENV
> 
> or whatever, something generic that we can use to protect any kind of
> interpreted script, it could check for uid changes as well as do an
> atsecure check to decide if it needs to cleanse the environment.

I think this is the wrong way around - it doesn't protect against the
race, and a perl or pythin script can easily clean its own environment
and doesn't need a helper program to do that.

The traditional method is to create an executable file that launches a
specific script, and make that executable suid, type transitioning or
whatever. This takes care of some issues such as LD_* variables
automatically.

The python wrapper Karl linked to does part of the job, but if you're
paranoid there are more things you need to protect against:

- other environment variables may be dangerous, for example program "foo"
  launched indirectly from the script may look at a FOORC variable to
  find its config file. In general it's safer to completely wipe the
  environment and only retain specific variables from a whitelist.

- set up file descriptors - close extra ones, and make sure 0/1/2 are
  open. A nasty hack is closing fd 2 (stderr) before launching the
  trusted app. The application opens a file for writing, gets fd 2 from
  the OS from that, and now anything it's intending to write to stderr
  such as warning or progress messages will also go to that file.

- make sure that resource limits are reasonable. Another hack involved
  setting the max file size to a very low value and calling passwd(1),
  which then truncated /etc/shadow due to the limit.

These things should be done for all suid/privileged programs, not just
scripts, because they may be using system(3) or equivalent to call a
program via the shell which could then get contaminated by $IFS or other
malicious settings.

-Klaus

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.