Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!steinmetz!dawn!stpeters
From: stpeters@dawn.steinmetz
Newsgroups: comp.unix.wizards
Subject: device file non-protection - and suid scripts
Message-ID: <7525@steinmetz.steinmetz.UUCP>
Date: Mon, 5-Oct-87 14:03:48 EDT
Article-I.D.: steinmet.7525
Posted: Mon Oct  5 14:03:48 1987
Date-Received: Thu, 8-Oct-87 05:06:49 EDT
References: <9615@brl-adm.ARPA>
Sender: root@steinmetz.steinmetz.UUCP
Reply-To: dawn!stpeters@steinmetz.UUCP (Dick St.Peters)
Organization: General Electric CRD, Schenectady, NY
Lines: 31

In article <9615@brl-adm.ARPA> bzs@bu-cs.bu.EDU (Barry Shein) writes:
>	if [ -x foo ]
>
>in a shell script would always return true for any file if you were
>root for some obscure reason.

A related example is that uid 0 can always open and write to *device*
files (/dev/widget etc.) even when the files are mode 000 (various
versions of SunOS and Ultrix).  We wanted a program to be able to
"lock" devices sufficiently to prevent even an SA from accidently
using them.

> I had written a simple shell script for
>the students called 'setpriv' which took either 'public' or 'private'
>and a list of files and did something reasonable with the permission
>bits.

Be *extremely* wary of suid shell scripts.  A local SA challenged me
to write one he couldn't break.  I lost every time (and learned a lot).

There is an *enormous* hole that is totally independent of the script
contents.  Show me a suid script, and I can be running as uid 0 in 10
seconds.  (BSD and derivatives at least, but I believe others as well.)

SunOS 3.2 closed this particular hole for csh (but not sh) suid
scripts, but I still wouldn't put one on my system.

Dick St.Peters                        
GE Corporate R&D, Schenectady, NY
stpeters@ge-crd.arpa              
uunet!steinmetz!stpeters