Messages in this thread |  | | Date | Mon, 16 Dec 1996 02:01:14 -0500 | From | cjf@nothinbu ... | Subject | security implications (was Re: Proposal: restrict link(2)) |
| |
Date: Fri, 13 Dec 1996 14:27:50 -0500 (EST) From: Dan Merillat <Dan@Merillat.org>
I understand quite clearly that making a link to a file does not affect either the data or the inode (aside from the link count.) However, link() has the rather unexpected side affect of allowing someone who is NOT the owner of a file to have the ability to prolong the lifespan of a file indefinitely. And that is a modification, and should be restricted to those with write access to the file, if not the owner.
Hmm, I just realized a security implication of this that I haven't seen mentioned. Suppose one of my users does the following (assuming /tmp and /usr are on the same partition): $ cd /tmp ; mkdir cjf ; cd cjf $ ln /usr/sbin/sendmail file $ ls -li file /usr/sbin/sendmail 49049 -rwsr-xr-x 2 root root 239024 Nov 17 22:53 /usr/sbin/sendmail 49049 -rwsr-xr-x 2 root root 239024 Nov 17 22:53 file
Now my user waits for the next sendmail bug to become widely known. Usually he can't exploit these because I upgrade sendmail before anyone has time to test the exploit code. So # install -o root -g root -m 4755 /whereever/sendmail-secure /usr/sbin/sendmail But $ ls -li file /usr/sbin/sendmail 49050 -rwsr-xr-x 1 root root 239024 Nov 17 22:53 /usr/sbin/sendmail 49049 -rwsr-xr-x 1 root root 239024 Nov 17 22:53 file is unexpected!
So what have I learned: o /tmp and /home and /usr should be on different partitions o I should run ls -i on all setuid binaries periodically (especially /before/ upgrading). (Perhaps?) 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). Debian users should look at /var/log/setuid.today. Anyone know where Red Hat stores this information? 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?
-- Christopher J. Fearnley | Nothin But Net System Engineering cjf@nothinbut.net, cjf@netaxs.com | UNIX SIG Leader at PACS http://www.netaxs.com/~cjf | (Philadelphia Area Computer Society) ftp://ftp.netaxs.com/people/cjf | Design Science Revolutionary "Dare to be Naive" -- Bucky Fuller | Explorer in Universe
|  |