Bugs in the "at" command - FIX DOES WORK!!!
bob at SU-SHASTA.ARPA
bob at SU-SHASTA.ARPA
Wed Jul 25 08:26:29 AEST 1984
The fix that I posted yesterday to the net to eliminate the security hole
in having "at" on System III & System V does indeed work! Matt is wrong
in claiming that it does not work!
The security hole was that once a user had used "at" to create a spool file
in the /usr/spool/at directory they could chown it away (like, to root).
The heart of my fix is the command 'chmod 700 /usr/spool/at'. Matt failed
to realize that this prevents users from then chowning their spool file,
/usr/spool/at/*, because they won't able to access /usr/spool/at anymore!
The "at" command and the "atrun" daemon can still access /usr/spool/at because
they run as root. I'm reposting the fix:
-------------------------------------------------------------------------------
The fix for making "at" secure under System III & System V is to do this:
chmod 700 /usr/spool/at
chown root /usr/spool/at
chmod 4755 /usr/bin/at
If your cron doesn't run as root also do:
chmod 4755 /usr/lib/atrun
chown root /usr/lib/atrun
The several versions of "at" that I've seen all chown the spool file to the
real UID so it's safe to make it set-uid and also prevent one from reading
files that the real UID isn't allowed to.
Note that no source changes or re-compilation is required.
Bob Toxen
Silicon Graphics
ucbvax!Shasta!olympus!bob
More information about the Comp.unix.wizards
mailing list