lkml.org 
[lkml]   [1996]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: security implications (was Re: Proposal: restrict link(2))
Date

> 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


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.028 / U:54.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site