Messages in this thread |  | | From | Keith Rohrer <> | Subject | Re: security implications (was Re: Proposal: restrict link(2)) | Date | Mon, 16 Dec 1996 01:59:52 -0600 (CST) |
| |
> So what have I learned: > o /tmp and /home and /usr should be on different partitions If you can manage it. You'd likely want to make /home separate to save hassle when upgrading/re-installing the system. /tmp being on its own filesystem can prevent some denial of service attacks.
> o I should run ls -i on all setuid binaries periodically (especially > /before/ upgrading). (Perhaps?) Something that gives not only the inode number (presumably this will change if someone gets root and replaces programs rather than being sneaky about it and rewriting them), timestamp, and size, but also the link count...
> o I need to really pay attention to the output of my script that reports > all setuid files on the system looking for any setuid files that I > didn't put there (especially ones outside /bin and /usr). No duh. :-)
> o Maybe there /is/ a security issue here that should be fixed? Or is > it just another gotcha that careful admins avoid by diligently > examining my previous point? Actually, there is. install, or scripts which use it to install suid binaries, should (according to the hole you just found) zero out the old file and/or warn about extra hard links before installing the new copy. In the general case it doesn't matter (though it should warn about extra links to the old version anyway), and in some cases there are hard links to not zero out (e.g. emacs used to install as emacs and emacs-version.number with hard links, so doing this would ruin the old "backup" binary).
Does anyone know if tripwire checks the link count? I'd hope it does...
Keith
|  |