Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 exptools; site whuxl.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!whuxl!mike
From: mike@whuxl.UUCP (BALDWIN)
Newsgroups: net.unix-wizards
Subject: Re: what are the implications of shell doing setuid(getuid())?
Message-ID: <712@whuxl.UUCP>
Date: Thu, 19-Sep-85 16:53:45 EDT
Article-I.D.: whuxl.712
Posted: Thu Sep 19 16:53:45 1985
Date-Received: Fri, 20-Sep-85 06:15:21 EDT
References: <2581@pegasus.UUCP> <1532@brl-tgr.ARPA>
Organization: AT&T Bell Laboratories, Whippany
Lines: 21

> > I was recently asked what the implications would be of having the shell do a
> > setuid(getuid()) and setgid(getgid()) as soon as it's invoked. The reason is
> > to try and plug up any security holes caused by set[ug]id programs that
> > invoke system(3C) or popen(3S). What tools are there that anyone knows of
> > that would be broken if this change were made, locally, or for real?
> 
> cpio, find, & sdiff all use popen() and tar uses system().
> Your proposed change could break their operation when these
> utilities are run privileged.  There are many other loopholes
> of equal or greater concern than "sh -c" that your shell
> mod would not take care of.  This seems like the wrong place
> to try to enforce security.

Nope:  cpio, find, sdiff and tar aren't setuid or setgid, so it doesn't
affect them at all.  It *only* affects setuid or setgid C programs that
exec the shell either directly, or through system() or popen().  This
loophole is quite large, why not fix it along with the others?
-- 
						Michael Baldwin
						AT&T Bell Labs
						{at&t}!whuxl!mike


Brought to you by Super Global Mega Corp .com