[1265] in linux-security and linux-alert archive
Re: [linux-security] Re: t bit and symlinks patch
daemon@ATHENA.MIT.EDU (David Holland)
Fri Oct 25 08:50:52 1996
From: David Holland <dholland@eecs.harvard.edu>
To: Andrew.Tridgell@anu.edu.au
Date: Thu, 24 Oct 1996 23:30:15 -0400 (EDT)
Cc: linux-security@tarsier.cv.nrao.edu, wietse@wzv.win.tue.nl
In-Reply-To: <96Oct21.235109+1000est.65060-27084+2445@arvidsjaur.anu.edu.au> from "Andrew Tridgell" at Oct 21, 96 11:51:07 pm
> 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.
Just for starters, this won't work - I can do
cd /tmp
md foo
cd foo
ln ../target-file hack
cd ..
mv foo/hack .
rd foo
If you disallow linking *to* files that are in +t dirs, I can
cd /tmp
md foo
cd foo
ln -s ../target-file proxy
ln proxy hack
rm proxy
cd ..
mv foo/hack .
rd foo
for the same effect. If you disallow making symlinks into directories
that are +t, I can make a link to /tmp and use that instead. If you do
that (and you make sure to do it right so if you make links to /tmp
you don't gain anything), I can still, in most environments,
manufacture such a link on another system and cause it to appear on
the target system via nfs or equivalent. You also run into problems
whenever somebody wants to make a symlink to a file that doesn't exist
yet.
You can also make symlinks to .. and move them around.
Frankly I think that this approach is not an effective use of
resources. You might get all these issues worked out eventually, by
which time you will have slowed down the filesystem enough doing extra
checks that nobody will want to use it. And you might not, in which
case the whole thing will turn out to have been a waste of time.
It'd probably be better to go start fixing the programs that use /tmp.
OpenBSD claims to have fixed nearly everything of the things they
maintain in their source tree.
[REW: In the far past, Unix didn't have a rename system call. The mv
program would create a new -=link=- to the file before removing the
old one. A cursory inspection of the above suggestions shows that this
would prevent Davids way to circumvent the suggested links-in-tmp-fix.
Right?]
--
- David A. Holland | VINO project home page:
dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino
