type transitioning script race condition?

type transitioning script race condition?

[Klaus Weidner]

Hello,

in the current refpolicy, quite a few script files have a *_exec_t type
and do a type transition. My understanding is that the transition happens
in the kernel in the execve() call, and then after transitioning the
kernel launches the interpreter (from fs/binfmt_script.c) and passes the
script name to the interpreter.

This sounds as if it suffers from the well known race condition that
makes setuid shell scripts a bad idea - is there any protection in place
to prevent users from exploiting the race condition to run code of their
own choice in the new domain?

The thread "labeling of compilers etc" on this mailing list (Feb this
year) touched on the subject but I didn't see a definite answer how this
is handled.

I've experimented a bit, running /usr/bin/yum as a normal user and using
Ctrl-Z to suspend it, and according to "ps axZ" output the python
process has the staff_u:staff_r:staff_t:SystemLow-SystemHigh context, and
doesn't seem to be transitioning. 

When run as root/sysadm_r, running "yum" appears to try to transition
(which incidentally produces an error and audit records, but that's a
different issue):

 # yum
 bash: /usr/bin/yum: /usr/bin/python: bad interpreter: Permission denied

 type=SELINUX_ERR msg=audit(1156698927.439:529): security_compute_sid: invalid context staff_u:system_r:rpm_t:s0-s15:c0.c255 for scontext=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c255 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=process
 type=SYSCALL msg=audit(1156698927.439:529): arch=40000003 syscall=11 success=no exit=-13 a0=83a6020 a1=83a9990 a2=83aabd8 a3=83a9a10 items=0 ppid=1754 pid=2080 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="bash" exe="/bin/bash" subj=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c255 key=(null)

-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.

Re: type transitioning script race condition?

[Russell Coker]

On Thursday 31 August 2006 08:39, Klaus Weidner <klaus@atsec.com> wrote:
> This sounds as if it suffers from the well known race condition that
> makes setuid shell scripts a bad idea - is there any protection in place
> to prevent users from exploiting the race condition to run code of their
> own choice in the new domain?

Correct.  As long as the script is run in a domain that has less privileges 
than the calling code this isn't a problem.  If running a script causes a 
transition to a more privileged domain then that's a policy bug.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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.

Re: type transitioning script race condition?

[Joshua Brindle]

Russell Coker wrote:

>On Thursday 31 August 2006 08:39, Klaus Weidner <klaus@atsec.com> wrote:
>  
>
>>This sounds as if it suffers from the well known race condition that
>>makes setuid shell scripts a bad idea - is there any protection in place
>>to prevent users from exploiting the race condition to run code of their
>>own choice in the new domain?
>>    
>>
>
>Correct.  As long as the script is run in a domain that has less privileges 
>than the calling code this isn't a problem.  If running a script causes a 
>transition to a more privileged domain then that's a policy bug.
>
>  
>
this happens quite a bit, including our own selinux management script 
semanage. In addition to the race condition (that is not fixable on 
Linux AFAIK) there are other environmental contamination issues,

There are some plans to fix the environmental contamination issues using 
a wrapper that cleanses the environment ala atsecure but the race is not 
fixable as far as I know.

--
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.

Re: type transitioning script race condition?

[Karl MacMillan]

On Wed, 2006-08-30 at 23:12 -0400, Joshua Brindle wrote:
> Russell Coker wrote:
> 
> >On Thursday 31 August 2006 08:39, Klaus Weidner <klaus@atsec.com> wrote:
> >  
> >
> >>This sounds as if it suffers from the well known race condition that
> >>makes setuid shell scripts a bad idea - is there any protection in place
> >>to prevent users from exploiting the race condition to run code of their
> >>own choice in the new domain?
> >>    
> >>
> >
> >Correct.  As long as the script is run in a domain that has less privileges 
> >than the calling code this isn't a problem.  If running a script causes a 
> >transition to a more privileged domain then that's a policy bug.
> >
> >  
> >
> this happens quite a bit, including our own selinux management script 
> semanage. In addition to the race condition (that is not fixable on 
> Linux AFAIK) there are other environmental contamination issues,
> 
> There are some plans to fix the environmental contamination issues using 
> a wrapper that cleanses the environment ala atsecure but the race is not 
> fixable as far as I know.
> 

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.

Karl



--
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.

Re: type transitioning script race condition?

[Joshua Brindle]

On Thu, 2006-08-31 at 09:23 -0400, Karl MacMillan wrote:
> On Wed, 2006-08-30 at 23:12 -0400, Joshua Brindle wrote:
> > Russell Coker wrote:
> > 
> > >On Thursday 31 August 2006 08:39, Klaus Weidner <klaus@atsec.com> wrote:
> > >  
> > >
> > >>This sounds as if it suffers from the well known race condition that
> > >>makes setuid shell scripts a bad idea - is there any protection in place
> > >>to prevent users from exploiting the race condition to run code of their
> > >>own choice in the new domain?
> > >>    
> > >>
> > >
> > >Correct.  As long as the script is run in a domain that has less privileges 
> > >than the calling code this isn't a problem.  If running a script causes a 
> > >transition to a more privileged domain then that's a policy bug.
> > >
> > >  
> > >
> > this happens quite a bit, including our own selinux management script 
> > semanage. In addition to the race condition (that is not fixable on 
> > Linux AFAIK) there are other environmental contamination issues,
> > 
> > There are some plans to fix the environmental contamination issues using 
> > a wrapper that cleanses the environment ala atsecure but the race is not 
> > fixable as far as I know.
> > 
> 
> 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.

I think we need to consolidate efforts because we are starting to work
on a wrapper here as well. 

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.

One thing, you said both issues can be mitigated, how can the race be
mitigated? The app executes the interpreter with the argv you pass into
it so the race to swap the file still exists (and the privilege has
already been raised via the wrapper)



--
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.

Re: type transitioning script race condition?

[Stephen Smalley]

On Wed, 2006-08-30 at 23:12 -0400, Joshua Brindle wrote:
> Russell Coker wrote:
> 
> >On Thursday 31 August 2006 08:39, Klaus Weidner <klaus@atsec.com> wrote:
> >  
> >
> >>This sounds as if it suffers from the well known race condition that
> >>makes setuid shell scripts a bad idea - is there any protection in place
> >>to prevent users from exploiting the race condition to run code of their
> >>own choice in the new domain?
> >>    
> >>
> >
> >Correct.  As long as the script is run in a domain that has less privileges 
> >than the calling code this isn't a problem.  If running a script causes a 
> >transition to a more privileged domain then that's a policy bug.
> >
> >  
> >
> this happens quite a bit, including our own selinux management script 
> semanage. In addition to the race condition (that is not fixable on 
> Linux AFAIK)

Solaris deals with the race by having the kernel set up the state of the
transformed process to include a descriptor to the script file and then
passing /dev/fd/<n> as the command line argument to the interpreter
rather than the original script pathname, IIRC.  There hasn't been much
receptiveness to doing something equivalent in Linux in the past on
lkml.

>  there are other environmental contamination issues,
> 
> There are some plans to fix the environmental contamination issues using 
> a wrapper that cleanses the environment ala atsecure but the race is not 
> fixable as far as I know.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: type transitioning script race condition?

[Joshua Brindle]

On Thu, 2006-08-31 at 10:43 -0400, Stephen Smalley wrote:
> On Wed, 2006-08-30 at 23:12 -0400, Joshua Brindle wrote:
> > Russell Coker wrote:
> > 
> > >On Thursday 31 August 2006 08:39, Klaus Weidner <klaus@atsec.com> wrote:
> > >  
> > >
> > >>This sounds as if it suffers from the well known race condition that
> > >>makes setuid shell scripts a bad idea - is there any protection in place
> > >>to prevent users from exploiting the race condition to run code of their
> > >>own choice in the new domain?
> > >>    
> > >>
> > >
> > >Correct.  As long as the script is run in a domain that has less privileges 
> > >than the calling code this isn't a problem.  If running a script causes a 
> > >transition to a more privileged domain then that's a policy bug.
> > >
> > >  
> > >
> > this happens quite a bit, including our own selinux management script 
> > semanage. In addition to the race condition (that is not fixable on 
> > Linux AFAIK)
> 
> Solaris deals with the race by having the kernel set up the state of the
> transformed process to include a descriptor to the script file and then
> passing /dev/fd/<n> as the command line argument to the interpreter
> rather than the original script pathname, IIRC.  There hasn't been much
> receptiveness to doing something equivalent in Linux in the past on
> lkml.
> 

Right, I'd be curious to see how many scripts this breaks, plenty of
applications (including scripts) look at argv[0] to see how they were
invoked to decide how to behave. 

Then again, if we really wanted this to eliminate the race we could
always do it from the wrapper..

Maybe this would be a good thing to do for security critical apps (eg.,
semanage) and not mess with everything else.

> >  there are other environmental contamination issues,
> > 
> > There are some plans to fix the environmental contamination issues using 
> > a wrapper that cleanses the environment ala atsecure but the race is not 
> > fixable as far as I know.
> 


--
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.

Re: type transitioning script race condition?

[Stephen Smalley]

On Thu, 2006-08-31 at 10:49 -0400, Joshua Brindle wrote:
> On Thu, 2006-08-31 at 10:43 -0400, Stephen Smalley wrote:
> > On Wed, 2006-08-30 at 23:12 -0400, Joshua Brindle wrote:
> > > Russell Coker wrote:
> > > 
> > > >On Thursday 31 August 2006 08:39, Klaus Weidner <klaus@atsec.com> wrote:
> > > >  
> > > >
> > > >>This sounds as if it suffers from the well known race condition that
> > > >>makes setuid shell scripts a bad idea - is there any protection in place
> > > >>to prevent users from exploiting the race condition to run code of their
> > > >>own choice in the new domain?
> > > >>    
> > > >>
> > > >
> > > >Correct.  As long as the script is run in a domain that has less privileges 
> > > >than the calling code this isn't a problem.  If running a script causes a 
> > > >transition to a more privileged domain then that's a policy bug.
> > > >
> > > >  
> > > >
> > > this happens quite a bit, including our own selinux management script 
> > > semanage. In addition to the race condition (that is not fixable on 
> > > Linux AFAIK)
> > 
> > Solaris deals with the race by having the kernel set up the state of the
> > transformed process to include a descriptor to the script file and then
> > passing /dev/fd/<n> as the command line argument to the interpreter
> > rather than the original script pathname, IIRC.  There hasn't been much
> > receptiveness to doing something equivalent in Linux in the past on
> > lkml.
> > 
> 
> Right, I'd be curious to see how many scripts this breaks, plenty of
> applications (including scripts) look at argv[0] to see how they were
> invoked to decide how to behave.

Yes, Solaris only does the /dev/fd/n substitution if the script
execution involves a change in identity/privs, presumably to avoid
creating compatibility issues with unprivileged scripts.

> 
> Then again, if we really wanted this to eliminate the race we could
> always do it from the wrapper..
> 
> Maybe this would be a good thing to do for security critical apps (eg.,
> semanage) and not mess with everything else.
> 
> > >  there are other environmental contamination issues,
> > > 
> > > There are some plans to fix the environmental contamination issues using 
> > > a wrapper that cleanses the environment ala atsecure but the race is not 
> > > fixable as far as I know.
> > 
> 
> 
> --
> 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.
-- 
Stephen Smalley
National Security Agency


--
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.

Re: type transitioning script race condition?

[Karl MacMillan]

On Thu, 2006-08-31 at 09:53 -0400, Joshua Brindle wrote:
> On Thu, 2006-08-31 at 09:23 -0400, Karl MacMillan wrote:
> > On Wed, 2006-08-30 at 23:12 -0400, Joshua Brindle wrote:
> > > Russell Coker wrote:
> > > 
> > > >On Thursday 31 August 2006 08:39, Klaus Weidner <klaus@atsec.com> wrote:
> > > >  
> > > >
> > > >>This sounds as if it suffers from the well known race condition that
> > > >>makes setuid shell scripts a bad idea - is there any protection in place
> > > >>to prevent users from exploiting the race condition to run code of their
> > > >>own choice in the new domain?
> > > >>    
> > > >>
> > > >
> > > >Correct.  As long as the script is run in a domain that has less privileges 
> > > >than the calling code this isn't a problem.  If running a script causes a 
> > > >transition to a more privileged domain then that's a policy bug.
> > > >
> > > >  
> > > >
> > > this happens quite a bit, including our own selinux management script 
> > > semanage. In addition to the race condition (that is not fixable on 
> > > Linux AFAIK) there are other environmental contamination issues,
> > > 
> > > There are some plans to fix the environmental contamination issues using 
> > > a wrapper that cleanses the environment ala atsecure but the race is not 
> > > fixable as far as I know.
> > > 
> > 
> > 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.
> 
> I think we need to consolidate efforts because we are starting to work
> on a wrapper here as well. 
> 
> 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 general solution is going to be a hard sell because of
compatibility problems. So I think it is best to go in two directions -
a practical per-application solution and the more complete and general
solution.

> One thing, you said both issues can be mitigated, how can the race be
> mitigated? The app executes the interpreter with the argv you pass into
> it so the race to swap the file still exists (and the privilege has
> already been raised via the wrapper)
> 

Sorry - started one message and sent another. If you embed the script
(as a string) and interpreter in the C wrapper you can avoid the race.

In practice - for the scripts we are discussing - if you have sufficient
privilege to modify the script or the environment to take advantage of
the race condition you likely have a more direct attack vector. So the
environment cleansing seems more important to me.

Karl



--
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.

Re: type transitioning script race condition?

[Joshua Brindle]

On Thu, 2006-08-31 at 11:29 -0400, Karl MacMillan wrote:
> On Thu, 2006-08-31 at 09:53 -0400, Joshua Brindle wrote:
> > On Thu, 2006-08-31 at 09:23 -0400, Karl MacMillan wrote:
> > > On Wed, 2006-08-30 at 23:12 -0400, Joshua Brindle wrote:
> > > > Russell Coker wrote:
> > > > 
> > > > >On Thursday 31 August 2006 08:39, Klaus Weidner <klaus@atsec.com> wrote:
> > > > >  
> > > > >
> > > > >>This sounds as if it suffers from the well known race condition that
> > > > >>makes setuid shell scripts a bad idea - is there any protection in place
> > > > >>to prevent users from exploiting the race condition to run code of their
> > > > >>own choice in the new domain?
> > > > >>    
> > > > >>
> > > > >
> > > > >Correct.  As long as the script is run in a domain that has less privileges 
> > > > >than the calling code this isn't a problem.  If running a script causes a 
> > > > >transition to a more privileged domain then that's a policy bug.
> > > > >
> > > > >  
> > > > >
> > > > this happens quite a bit, including our own selinux management script 
> > > > semanage. In addition to the race condition (that is not fixable on 
> > > > Linux AFAIK) there are other environmental contamination issues,
> > > > 
> > > > There are some plans to fix the environmental contamination issues using 
> > > > a wrapper that cleanses the environment ala atsecure but the race is not 
> > > > fixable as far as I know.
> > > > 
> > > 
> > > 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.
> > 
> > I think we need to consolidate efforts because we are starting to work
> > on a wrapper here as well. 
> > 
> > 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 general solution is going to be a hard sell because of
> compatibility problems. So I think it is best to go in two directions -
> a practical per-application solution and the more complete and general
> solution.
> 

it will only do anything in the case of atsecure being set, most of the
time this shouldn't cause compatibility problems. If something that has
atsecure set (and therefore has some security change like setuid or a
domain transition) and it breaks then the script has a major security
issue anyway. I don't see this as a problem at all.

> > One thing, you said both issues can be mitigated, how can the race be
> > mitigated? The app executes the interpreter with the argv you pass into
> > it so the race to swap the file still exists (and the privilege has
> > already been raised via the wrapper)
> > 
> 
> Sorry - started one message and sent another. If you embed the script
> (as a string) and interpreter in the C wrapper you can avoid the race.
> 

right.. 

> In practice - for the scripts we are discussing - if you have sufficient
> privilege to modify the script or the environment to take advantage of
> the race condition you likely have a more direct attack vector. So the
> environment cleansing seems more important to me.

maybe, you might not be able to write to the type of the script but if
you can, for some reason, copy over it with a different script of a
different type then you can take advantage. This should be mitigated by
policy for the most part, environment cleansing is currently an achilles
heel.


--
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.

Re: type transitioning script race condition?

[Klaus Weidner]

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.

Re: type transitioning script race condition?

[Klaus Weidner]

On Thu, Aug 31, 2006 at 11:29:24AM -0400, Karl MacMillan wrote:
> Sorry - started one message and sent another. If you embed the script
> (as a string) and interpreter in the C wrapper you can avoid the race.

Yes, the important thing is to ensure that raising the privileges and
picking the thing to execute is a single operation.

> In practice - for the scripts we are discussing - if you have sufficient
> privilege to modify the script or the environment to take advantage of
> the race condition you likely have a more direct attack vector. So the
> environment cleansing seems more important to me.

You don't need to modify the script or have special privileges to exploit
the race condition. A possible example looks like this:

- create link to executable (the link can be one of the path components),
  for example:

	ln -s /usr/sbin /tmp/hack

- execute /tmp/hack/semanage

- kernel looks at label of /tmp/hack/semanage, gets the label of
  /usr/sbin/semanage

- kernel decides to do a domain transition, suid, whatever

- kernel executes: /usr/bin/python /tmp/hack/semanage

- attacker redirects /tmp/hack to /tmp/malicious/ which contains a
  different semanage script

- python opens /tmp/hack/semanage which now resolves to
  /tmp/malicious/semanage

(As an aside, I think in this specific case the AppArmor approach of
making the security decisions based on the path name is actually safer
than using the file label. Time for a flame war about "label based
security considered harmful"? ;-)  But the real solution is to avoid the
race in the first place.)

-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.

Re: type transitioning script race condition?

[Joshua Brindle]

On Thu, 2006-08-31 at 10:46 -0500, Klaus Weidner wrote:
> 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 race is insignificant compared to the environment. The scripts
cannot clean their own environment because the environment affects the
interpreters potentially before the script is started (like PATH
variables specific to the interpreter, or preload like PYTHONSTARTUP
(run before the script is started).

> 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.
> 

right, only the variables that affect the linker, not ones that affect
the interpreter.

> 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.
> 

applications that use their own environment and are trusted within a
specific domain are a non-issue, we already trust them to act
appropriately within the confines we've given.

> - 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.
> 

right, I mentioned this in another email, we could do this for security
critical apps like semanage but not in a general way.

> - 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.
> 

not sure why this helps.

> 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.

privileged programs already handle this if they are binary (atsecure
cleanses things that can affect the binary that are out of its control)


--
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.

Re: type transitioning script race condition?

[Karl MacMillan]

On Thu, 2006-08-31 at 11:02 -0500, Klaus Weidner wrote:
> On Thu, Aug 31, 2006 at 11:29:24AM -0400, Karl MacMillan wrote:
> > Sorry - started one message and sent another. If you embed the script
> > (as a string) and interpreter in the C wrapper you can avoid the race.
> 
> Yes, the important thing is to ensure that raising the privileges and
> picking the thing to execute is a single operation.
> 
> > In practice - for the scripts we are discussing - if you have sufficient
> > privilege to modify the script or the environment to take advantage of
> > the race condition you likely have a more direct attack vector. So the
> > environment cleansing seems more important to me.
> 
> You don't need to modify the script or have special privileges to exploit
> the race condition. A possible example looks like this:
> 
> - create link to executable (the link can be one of the path components),
>   for example:
> 
> 	ln -s /usr/sbin /tmp/hack
> 

In a strict environment the creation of the symlinks to privileged
applications should be controlled.

> - execute /tmp/hack/semanage
> 
> - kernel looks at label of /tmp/hack/semanage, gets the label of
>   /usr/sbin/semanage
> 
> - kernel decides to do a domain transition, suid, whatever
> 
> - kernel executes: /usr/bin/python /tmp/hack/semanage
> 
> - attacker redirects /tmp/hack to /tmp/malicious/ which contains a
>   different semanage script
> 
> - python opens /tmp/hack/semanage which now resolves to
>   /tmp/malicious/semanage
> 

Good point. Seems like a less invasive option than opening the file
descriptor is to pass in the target of the symlink instead of the
symlink, but this has several other problems.

> (As an aside, I think in this specific case the AppArmor approach of
> making the security decisions based on the path name is actually safer
> than using the file label. Time for a flame war about "label based
> security considered harmful"? ;-)  But the real solution is to avoid the
> race in the first place.)
> 

Well, this is more a problem that the privilege escalation is not
properly tied to the entrypoint object, which is why this is a problem
for both suid and selinux - in which both _correctly_ associate security
attributes with the object :).

This should be fixed for semanage. Actually, things are even worse since
semanage has "#! /usr/bin/env python" - no need to try to exploit a race
condition when you can just execute whatever you want with privileges as
long as it is called python.

Karl


--
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.

Re: type transitioning script race condition?

[Klaus Weidner]

On Thu, Aug 31, 2006 at 12:13:14PM -0400, Joshua Brindle wrote:
> The race is insignificant compared to the environment. The scripts
> cannot clean their own environment because the environment affects the
> interpreters potentially before the script is started (like PATH
> variables specific to the interpreter, or preload like PYTHONSTARTUP
> (run before the script is started).

perl has a couple of features to support suid execution, mainly the
"taint" mode which is activated automatically when it detects that it's
running setuid, and which can be specified on the #! line so that it's
activated race-free by the kernel. In that mode, it ignores variables
like PERLLIB automatically.

I'm not sure how Python handles it, and I'm not disagreeing with you in
general, it *is* very important to clean the environment and I think it's
safest to do this in the wrapper program.

> On Thu, 2006-08-31 at 10:46 -0500, Klaus Weidner wrote:
> > - 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.
> 
> applications that use their own environment and are trusted within a
> specific domain are a non-issue, we already trust them to act
> appropriately within the confines we've given.

I think it's more dangerous than that - if you use a blacklist approach
to clean the environment, you're likely to miss variables which
indirectly affect things.

For example, say /usr/sbin/trustedapp is a shell script, and your wrapper
takes care to sanitize all environment variables that the shell cares
about (IFS, PATH, ...). But /usr/sbin/trustedapp contains a perl
one-liner, and you haven't sanitized PERLLIB, PERL5OPT, PERLDB_OPT etc,
so the trusted app ends up running user specified code at its current
privilege level due to that. You'd have to do a lot of analysis to find
all the potentially dangerous options, and it's a lot simpler to use a
whitelist.

> > - 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.
> 
> not sure why this helps.

Well, this example is a denial of service, and I can't think of an
example how to use it to gain privileges, so I agree that it's probably
less critical. But it wouldn't surprise me if people find creative ways
to abuse such limits.

> > 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.
> 
> privileged programs already handle this if they are binary (atsecure
> cleanses things that can affect the binary that are out of its control)

atsecure doesn't do anything to protect against indirect effects, for
example if the C app uses system(3) without cleaning IFS and PATH first,
so it's not sufficient to rely on the atsecure mechanism alone. You're
right that it's good protection against things out of the binary's
control, but it's important for it to do the security measures that are
under its control.

-Klaus

-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.

Re: type transitioning script race condition?

[Klaus Weidner]

On Thu, Aug 31, 2006 at 12:39:10PM -0400, Karl MacMillan wrote:
> On Thu, 2006-08-31 at 11:02 -0500, Klaus Weidner wrote:
> > - create link to executable (the link can be one of the path components),
> >   for example:
> > 
> > 	ln -s /usr/sbin /tmp/hack
> 
> In a strict environment the creation of the symlinks to privileged
> applications should be controlled.

Yes, but this gets tricky in a case like this where the symlink just
points to a directory used as a path component, and stat()ing the
executable file won't reveal that it's accessed through a link.  You'd
need to very restrictive about symlinks, for example not permitting links
pointing to something you don't own or can't write.

-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.

Re: type transitioning script race condition?

[Karl MacMillan]

On Thu, 2006-08-31 at 12:19 -0500, Klaus Weidner wrote:
> On Thu, Aug 31, 2006 at 12:39:10PM -0400, Karl MacMillan wrote:
> > On Thu, 2006-08-31 at 11:02 -0500, Klaus Weidner wrote:
> > > - create link to executable (the link can be one of the path components),
> > >   for example:
> > > 
> > > 	ln -s /usr/sbin /tmp/hack
> > 
> > In a strict environment the creation of the symlinks to privileged
> > applications should be controlled.
> 
> Yes, but this gets tricky in a case like this where the symlink just
> points to a directory used as a path component, and stat()ing the
> executable file won't reveal that it's accessed through a link.  You'd
> need to very restrictive about symlinks, for example not permitting links
> pointing to something you don't own or can't write.
> 

And perhaps the bigger issue is that I am totally making up the ability
to control what target a symlink has (as was pointed out by Dave Caplan
in a private mail). The only control we get is the creation of symlinks
not control over their targets.

Karl


--
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.

Re: type transitioning script race condition?

[Stephen Smalley]

On Thu, 2006-08-31 at 10:46 -0500, Klaus Weidner wrote:
> - 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.

Just FYI, glibc ensures that fd 0/1/2 are allocated for programs that
involve a uid, gid, or context transition.  So given a binary wrapper
that uses glibc, you get that part for free.

> - 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.

The SELinux setrlimit and rlimitinh permission checks were designed to
counter that attack; the former limits what processes can change their
hard limits so that the hard limit can be used as a safe reset point for
the soft limit upon exec, and the latter controls whether the soft
limits are reset across a context transition.  In that model, you limit
the ability to set the hard limit to programs trusted for that purpose,
like login (via pam_limits).

The SELinux siginh permission check further addresses inheritance of
signal-related state across such transitions.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: type transitioning script race condition?

[Russell Coker]

On Thursday 31 August 2006 23:53, Joshua Brindle <method@manicmethod.com> 
wrote:
> 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

Do all interpreters have the same requirements for environment cleaning?  Is 
there a case where cleaning the environment for interpreter A will break 
interpreter B in some way?

> and when the wrapper is run it looks at how it was run argv[0] and
> checks a config file, something like:

We are talking about a wrapper that does something similar to suid-perl.  The 
security history of suid-perl isn't that good, I am concerned that a program 
which is designed to suit more than one interpreter will be harder to 
secure...

http://www.coker.com.au/selinux/talks/ols2003/

In the paper I presented at OLS 2003 I considered some options for domain 
transitions with a single program.  I was looking at busybox, but a single 
interpreter with multiple scripts will work in similar ways.

If we were to have hundreds of types used for domain transitions then there 
would be an administrative burden in configuring the system which was not a 
factor I considered in my paper (I was just looking at the needs of programs 
that are parts of busybox).  In such a case the single wrapper would offer 
some benefits at the cost of slightly weakening security.

Will we have hundreds of types used for such transitions?  Or will the number 
of scripts that require domain transitions for correct operation be small 
enough that a wrapper for each is possible?

If there is only a small number of types used for scripts then we can have a C 
wrapper that causes the transition.

So you have /usr/bin/a.sh and /usr/bin/b.sh being shell scripts with the type 
bin_t and /usr/bin/a and /usr/bin/b being executables labeled with types to 
cause domain transition which would then execute the shell scripts.  Before 
executing the shell scripts they could change the environment as necessary.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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.

Re: type transitioning script race condition?

[Joshua Brindle]

On Fri, 2006-09-01 at 22:48 +1000, Russell Coker wrote:
> On Thursday 31 August 2006 23:53, Joshua Brindle <method@manicmethod.com> 
> wrote:
> > 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
> 
> Do all interpreters have the same requirements for environment cleaning?  Is 
> there a case where cleaning the environment for interpreter A will break 
> interpreter B in some way?
> 

you seem to have skipped the bottom half of my email where I proposed a
configuration file for the wrapper that instructed it how to behave for
each interpreter it wraps.

> > and when the wrapper is run it looks at how it was run argv[0] and
> > checks a config file, something like:
> 
> We are talking about a wrapper that does something similar to suid-perl.  The 
> security history of suid-perl isn't that good, I am concerned that a program 
> which is designed to suit more than one interpreter will be harder to 
> secure...
> 

It can't be worse than it is now:

[root@twoface ~]# cat ./os.py
import selinux

(ret,con) = selinux.getcon()
print "I'm running in"
print con

[root@twoface ~]#
PYTHONPATH=.:/usr/lib64/python2.4/site-packages/ /usr/sbin/semanage
I'm running in
user_u:system_r:semanage_t



--
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.