tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: autoclean mode for tmpfs

On Sun, Aug 07, 2011 at 12:11:49PM -0400, Mouse wrote:
 > > It's a security FAQ. If you do rm -rf (or nearly any of the other
 > > obvious/easy alternatives) in a world-writable directory, a hostile
 > > user can interact with it to erase any file on the system.
 > I believe that this is partially fixable: provided there is at least
 > one file descriptor available per directory level, I think it is
 > possible to safely remove everything but directories.  Most briefly,
 > fchdir to each directory, stat . and make sure it matches the directory
 > we thought we chdired into (to avoid doing damage if we lose a symlink
 > race).  Then delete things using relative-to-. paths and fchdir back
 > out.

I'd suggest that anyone interested in this look into (perhaps the
history of) Red Hat's tmpwatch, which does roughly this but was also
overengineered and thrashed on until believed safe by the security
community. It forks for every level; I don't remember if this is
because a subtle problem that arises if you don't or if it's just
because linux doesn't/didn't handle fchdir correctly. It's been a

 > However, since there's no way to make rmdir(2) use NOFOLLOW, we
 > have to either leave directory structure in place or risk removing an
 > attacker's choice of empty directories.


valkyrie% ls -l
total 4
drwx------  2 dholland  notmp  512 Aug  7 12:32 bar
lrwx------  1 dholland  notmp    3 Aug  7 12:32 baz -> bar
valkyrie% rmdir baz
rmdir: baz: Not a directory
Exit 1

 > Not that this makes it any easier to do the usual find | xargs rm style
 > of cleanup, though.  To do it safely in the way I refer to above would
 > require doing it all inside rm.  Might be worth doing, but quite
 > possibly better done in the filesystem, to (a) avoid the need for the
 > file descriptors, (b) delete a file here and a file there rather than
 > the wholesale destruction of rm -rf (even if I'm right about it being
 > possible to make it safe against hostile users), and (c) get
 > directories right.


(particularly in tmpfs, since tmpfs is already for transient data)

David A. Holland

Home | Main Index | Thread Index | Old Index