Subject: Re: CRITICAL ** Holes in default cron jobs ** CRITICAL
To: None <current-users@NetBSD.ORG>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
List: current-users
Date: 12/30/1996 19:55:02
>>>>> "der" == der Mouse <mouse@Holo.Rodents.Montreal.QC.CA> writes:
    >> I'd like to suggest that we generalize the solution by making
    >> all the rm commands only remove files owned by root,bin,daemon.

    der> I'd assume you mean _not_ remove such files. :-)

  Although I have I bad habit of missing negatives, this wasn't one of
them.

  I guess it depends.
  If you are removing #*, *~ etc, files, then root should only remove
root's files. Perhaps always doing the deletion with the permissions
of the user who'se files they are.
  /etc/daily removes the file following things:
	/tmp files not accessed in 3 days
	/tmp directories not accessed in 1 day
	/var/tmp files not accessed in 7 days
	/var/tmp directories not accessed in 1 day
	/scratch files/dirs 1 day
	/var/preserve 7 days
	/var/rwho     7 days
	/	- lists *.core files
	/	- remove [#,]*                   \
	/	- remove .#*			 |
	/	- remove a.out                   + 3 days no access
	/	- remove *.CKP	(what is this?)  |
	/	- remove .emacs_[0-9]*           /

  It is presumably these files that are at risk of the symlink
bait/switch.

    >> All those simply generate a warning to root.  Perhaps with a
    >> script to do the actual rm squirrelled away somewhere.

  By warning, I mean, a message in an emailed report. E.g.
"please remove the following files. You can do so by executing /etc/rootjobs/rm12345"

    der> the kernel know what UIDs are "special", which is pretty
    der> gross.  (It's bad enough having it know about UID 0
    der> specially.)  And of course it doesn't affect anything but
    der> unlink()....

    der> To be sure, teaching the kernel about multiple special UIDs
    der> is something I've been meaning to do, but in a more general
    der> context, not just a special case for unlink().

  I wonder if ten well chosen group id's with a default expanded (to
64) group id vector might not deal with a lot of things. E.g. group
"daemon" should be able to bind port <1024. (I am *not* including rsh
usage, just server usage)
  
   :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: mcr@sandelman.ottawa.on.ca. PGP key available.