Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!encore!bzs@xenna
From: bzs@xenna (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: System V Release 4 ...
Message-ID: <3947@encore.UUCP>
Date: 22 Oct 88 17:32:27 GMT
References: <467@gould.doc.ic.ac.uk> <12843@ncoast.UUCP>
Sender: news@encore.UUCP
Reply-To: bzs@xenna (Barry Shein)
Organization: Encore Computer Corp
Lines: 29
In-reply-to: allbery@ncoast.UUCP (Brandon S. Allbery)

>Shell scripts probably -- HOPEFULLY -- cannot be suid/sgid.  ALLOWING SETUID
>SHELL SCRIPTS IS A SECURITY HOLE.  It's notable that Berkeley itself has
>sent out a "mandatory" BSD patch which disables setuid on "#!" executables.
>
>++Brandon

Although I fully believe that setgid/uid shell scripts are a security
hole why would the kernel enforce this? All setid programs are a
potential security hole and generally only very careful wizards can
assure reasonable safety, no one can make security programming
"user-friendly", at least not without generally castrating the system.

Not allowing me to create a setid shell script seems to assume that I
am a) interested in security on this particular machine (eg. my home
unix system or other personal workstation only I can log into anyhow)
and b) that I am too stupid (but not stupid enough) to defeat this
questionable "feature" by setuiding a C program which just does a
system() or other exec*() of the script.

Or am I missing something here and the hole is open to non-priv'd
users such that they can attain root (or similar) status even tho I,
as root, have not created any setuid/setgid scripts on my system? If
so then I could go along with the above fix if no reasonable
workaround to that problem can be thought of. The only holes I am
aware of either involve the existence of a priv'd script created by a
priv'd user or remote file system hacking which is just as open to any
programming, not just shell scripts.

	-Barry Shein, ||Encore||