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