[1256] in linux-security and linux-alert archive
Re: [linux-security] Re: t bit and symlinks patch
daemon@ATHENA.MIT.EDU (Andrew Tridgell)
Thu Oct 24 13:40:43 1996
From: Andrew Tridgell <tridge@arvidsjaur.anu.edu.au>
To: linux-security@tarsier.cv.nrao.edu
CC: wietse@wzv.win.tue.nl
In-reply-to: <199610191237.OAA29013@wzv.win.tue.nl> (wietse@wzv.win.tue.nl)
Reply-to: Andrew.Tridgell@anu.edu.au
Date: Mon, 21 Oct 1996 23:51:07 +1000
Wietse wrote:
> To my surprise the discussion focuses entirely on symlink attacks from
> world-writable directories. I remind the reader that many of these
> attacks are also possible when sensitive files can be hardlinked to,
> for example, the /tmp directory.
You're dead right. I plan on doing an updated patch that fixes this
and also addresses some of the other ideas people have sent me.
I think we need to fix the hard link problem at link creation time
rather than by checking for link counts at lookup time, because once
the hard link is created its impossible to tell who created it, and
thus we couldn't allow for root creating hard links in /tmp (which can
be useful)
So I propose that we disallow the creation of a hard link in a
directory with the t bit set if the file being linked to is not owned
by the process (as determined by the fsuid). This would not apply to
processes with fsuid==0.
So the full set of semantic changes would be:
1) don't follow symlinks in directories with the t bit set if the
fsuid does not match the owner of the link, and the owner of the link
is not root. This specifically includes the case where the fsuid is 0.
2) don't allow a process with fsuid!=0 to create a hard link in a
directory with the t bit set to a file that it does not own.
The 1st rule requires a change in fs/namei.c:follow_link() that I
posted before
The 2nd rule will require a few simple lines to be added to
fs/namei.c:do_link()
Some people have suggested more radical rules but I don't think they
are warranted. I'm trying to come up with the minimum changes that
make /tmp secure while not impacting significantly on legitimate uses.
As far as configurability, I'd like to see these changes become the
default, just like the changes that were made to eliminate setuid
shell scripts, and the ones that drop source routed IP packets. I
think these changes are of a quite different nature to the nosuid and
noexec options, as those options would break the average linux system
if they were on by default, whereas the proposed symlink and link
changes should not be noticed on the vast majority of systems.
The only "normal" things that might break is when people create a set
of soft links in /tmp (perhaps using lndir) to setup some directory
structure for a friend. I think that its not too much to ask people
doing this to create a /tmp/user directory and put their links in
there (this is quite safe).
Without these changes there are just too many security holes waiting
to happen in /tmp. The fact that you can wipe out files owned by
anyone (including root) that runs gcc should give us all pause to
think :-)
Andrew
