Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!uwmcsd1!marque!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Secure setuid shell scripts
Message-ID: <309@auspex.UUCP>
Date: 26 Oct 88 17:30:44 GMT
References: <14066@iuvax.cs.indiana.edu> <4409@bsu-cs.UUCP> <14069@mimsy.UUCP> <546@sp7040.UUCP> <14139@mimsy.UUCP> <4483@bsu-cs.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 21


 >The set-user-id shell script bug, they say, lies in the semantics of
 >the file system itself.  Very well:
 >
 >In article <14139@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) adds:
 >>...there is a way to have set-ID scripts without having
 >>the kernel do it: you make the interpreter itself set-ID, and have it
 >>check the ID on the script.
 >
 >Which naturally leads me to wonder:  The semantics of the filesystem
 >are presumably not dependent on whether the kernel handles set-uid
 >scripts or the set-uid interpreter does (or are they?).  Does the same
 >security hole exist when a shell, which has been made made set-uid to
 >root, executes a set-uid scrpt without the kernel's help?

I don't know that I'd say it "lies within the semantics of the file
system" in the sense you may be thinking of.  It lies, in part, with the
way "#!" is implemented, and in part with the way some other system
calls work.  The same security hole (at least the one I'm familiar with,
which I think is the one being discussed here) doesn't exist if the
shell is made set-UID and executes it without the kernel's help.