Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ece-csc!ncsuvx!gatech!udel!rochester!bbn!spdcc!ima!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.wizards
Subject: Re: System V Release 4 ...
Message-ID: <109@minya.UUCP>
Date: 18 Oct 88 02:10:36 GMT
References: <467@gould.doc.ic.ac.uk> <13958@mimsy.UUCP>
Organization: (none)
Lines: 54

> There is a large and nasty (but very friendly-looking) bug hiding behind
> set-ID shell scripts.  The bug is embedded in the file system semantics.
> (Actually, I do know how to fix it, even under NFS, though it is not
> pretty, and I have never really liked set-ID scripts anyway.)

This is something I've been hearing for some time, and wondering when
the people who understand the supposed security problem are going to
enlighten the rest of us.

It's not even obvious that such a claim is credible.  As a null
hypothesis, I'd make a fairly obvious suggestion:  All programming
languages are equal security risks until proven otherwise.  

To be more specific, I'd sure like to know what it is about the
shell programming languages (Bourne, C, K, T, etc...) that make
them more risky than a C program.  I don't believe there's anything
magical about C that makes it less a security risk than any other
language.  If anything, I'd give more credit to a claim that C
is the dangerous one.  I'm sure the the partisans of Ada, not
to mention those of Pascal, Fortran, Lisp, etc., are not too 
happy with a claim that C programs are the only ones that can
be trusted to be setu/gid.  If that is the claim.

Or perhaps the claim is that interpreted languages are inherently
security risks.  Can someone justify this one?  It seems false
on its face, as a setuid compiled program can always exec an
interpreter, and the interpreter will then be running under the
setuid permissions.  

Or is the suggestion perhaps to make exec*() calls change the
permissions to something unspecified by the execing program?
I'd be a bit surprised if this gains you anything (other than
surprises for unsuspecting super-users who start up a program
that looks like it is setuid to someone else (like uucp), not
suspecting that it will exec a subprocess that will run as root.
I can think of lots of fun things to do on a system that does
this.

Anyhow, enough rambling.  Just what is this supposed security bug
that infects setuid shell scripts but not C programs?  Why are C
programs more trustworthy?  Or is that even the claim?  Are Ada
and Lisp programs equally (un)trustworthy?  Can you prove it?

[Yes, I know, I'm bound to get a lot of flames telling me what
an incredibly ignorant idiot I am for not understanding it all
without being told.  Save your fingers.  I've been told that lots
of times before, and more insults won't smarten me up a bit.  But 
hard information might.  ;-]

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]