🚀 go-pugleaf

In article <=k+yj3h@rpi.edu> gad@eclipse.its.rpi.edu (Garance A. Drosehn) writes:
>The writeup suggests that /etc/disk be made setuid root.

Whoa! majorly bad idea.

>I didn't like that idea at all, so I patched  
>CDPlayer0.8 (the nextstep front-end to cdplayer) to reference  
>/usr/local/bin/E_CD instead of the "/usr/etc/disk %s" that I noticed in the  
>object module.  (that's probably not the exact string I replaced, as what I  
>replaced had the same number of letters as /usr/local/bin/E_CD).
>
>The E_CD file is a setuid root script with two lines, as follows:
>
>echo "`/bin/date | /bin/sed -e 's/^....//' -e 's/E[SD]T 199.$//'`- ejecting  
>CD-ROM: " > /dev/console
>(/usr/etc/disk -e /dev/rsd2h) > /dev/console

The patch is a GOOD idea, however the script is a bad one. The best way to
do this is to create a new group, say 'cdrom', chown and chmod the device
so it is owned and rwx by this group. Then write a small C program which
issues ioctl DKIOCEJECT (nextdev/disk.h) on the device and do one of:

- make the C program setgid to that group 'cdrom', this will allow everyone
   to use it, but only on that device.
- put everyone who needs to use it in that group 'cdrom', this will restrict
   access to only those in the group 'cdrom'

>Of course, I believe I saw somewhere else that scripts which are setuid root  
>are also security problems.

In theory setuid scripts are "safe" if you use absolute pathnames for
EVERYTHING, however, I still have my doubts, and besides there is an old
bug (IFS) which means a setuid script will NEVER be safe on the NeXT as
far as 2.x is concerned (might be fixed in 3.0)
Stay away from setuid scripts if internal security is a concern.

>Sigh.  On the other hand, I saw somewhere  
>*else* that the setuid script problem did not apply to NeXTs.  Anyone know  
>more about that?

No, that's wrong, flat out wrong, if anything they are MORE of a problem
on the NeXT than other platforms.

la la la,
-- 
:: Christopher Lloyd :: a74k110@titan.ucc.umass.edu :: Yrrid, Inc. ::