On the Correctness of Set-User-ID programs

[utzoo!decvax!ucbvax!unix-wizards]

>From Eps at UCLA-SECURITY Mon Aug 24 17:06:31 1981
Random comments:

Locking: As I recall, passwd(1) links /etc/passwd to /etc/ptmp as
a lock in V7 Unix.

General: Unix/TS and its derivatives set the uid in the proc
table from RUID, so a user can kill(1) a SUID program.

Unix-V7: as for /tmp being writable, I've seen quite a few
Unix systems that have the following lines in /etc/rc:
	cd /tmp
	rm -f *
Needless to say, PATH was set to something like ":/bin:/usr/bin:/etc"

Unix-V7: cithep's solution to the at(run) problem is to create
the files in /usr/spool/at with mode 6744.  atrun will refuse
to run a file without both SUID and SGID.  This is especially
important since the owner of a file (as well as the superuser)
can chown(chgrp) files (although set bits get reset if the
user isn't super and the uid/gid don't match the euid/egid) on
that system.  This way at(1) is left unprivileged, and
/usr/spool/at is left writable.

I've found that set-gid is sufficient for most "magic" programs,
and that set-uid-root is only needed when the full capabilities
of the Superuser are essential.  The authors also failed to
mention the tremendously useful access(2) call, which is not
easily 
available to SUID shell scripts.  access() is fairly
cheap insurance when checking permissions on an existing file,
it does get a little trickier when you want to see if you can
"safely" do a creat() call on behalf of the RUID.  One of
the things I've found annoying is that there is no way to
"temporarily disable your privileges"--you can only throw
them away.  This case crops up when a set-uid-not-root
program needs to open a file that only the RUID can.  One
possible solution to this problem might be the addition of
xchuid() and xchgid() calls, to swap Rs and Es.  Comments?

					--Eric
-------