at(1) security breach summary of replies

[silver at csu-cs.UUCP]

CONDENSED SUMMARY:

    Thanks for the answers!  I received  eight replies, all  essentially
    correct  and in  agreement.  The bottom line is:  at(1), as shipped,
    is  incompatible  with kernels  which permit any user to give away a
    file  via  chown(2).  I did not  realize  that V7  chmod(2),  unlike
    Systems III and V, does NOT allow mere mortals to give away files.

LONG-FORM SUMMARY:

    Key points from original question:

	What is to prevent a user from using  chown(1) to "give away" an
	"at" file to the super-user so it runs privileged?

	Note that at(1) mysteriously disappeared from System III.  Could
	this be the reason why?

    Samplings from replies:

	1) Spool directory must be protected:
		rwx------- root  /usr/spool/at
	   will do nicely.
	2) But now at can't open the file.
	   Have to make at setuid root and add code to  setuid(getuid())
	   or chown after creating the spool file.

	Look  around line 28 in atr.c.  In USG, chown and chgrp turn off
	all  setuid/gid  bits before  changing  the  owner/group.  atr.c
	checks to see that if the  owner is root,  /usr/at/J*  must have
	setuid root, and if it has group 5, it has setgid group.

	Initiate an at, look at /usr/at/J*, chown it to root and look at
	its permissions.  The setgid is off.

	The fix is to hack the kernel so that only a superuser can chown
	a file.

	You might be  surprised  at how many systems  still  posess this
	bug, and it's one of the better known ones.

	"at" may not have  ever  been in USG  UNIX;  not  everything  in
	Research UNIX (i.e., V6, V7) gets into the production USG UNIX.

Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado
ucbvax!hplabs!hpfcld!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"