Re: stat to open race condition (was Re: [Integrit-users] Re: integrit)

[lumpy <lu...@9m...>]

I am concerned about it - lets say youre checking /tmp and someone has a
regular file there, then, on the second run the file is switched with a
fifo, integrit will hang, no?

I thought the whole point of an integrity checker was to run to see if
files have changed.

If instead of the double stat, you opened it and passed a descriptor, you
would get around the race, although, you would still have to do another
check if the file was a symlink (if you cared, but, thats really not 
so important in this particular scenario)

On 20 Feb 2001, Ed L Cashin wrote:

> lumpy <lu...@9m...> writes:
> 
> > are you saying that youll never be checking any files that have an
> > ownership other than root, then?
> 
> No, it's just that checksums are only done on regular files.  I just
> checked and fifos do not test as regular files on FreeBSD.
> 
> > Im on freebsd, but, the i think its a general rule.  if you stat the
> > file, and then do an open on it, theres that race, meaning you can
> > swap between a fifo and a regular file.  causing integrit to hang
> > could allow the attacks to go on without it reporting anything.
> 
> Oh, I see now what you mean now: an attacker could mv a fifo to the
> filename that we just did a stat on.  This is what I was talking about
> when I said that on a compromised machine integrit (or any similar
> tool) may not run properly.  There are a zillion ways to undermine a
> running process when you have root, and it's not really helpful to try
> to fight that reality.
> 
> Using fstat as a second stat on every regular file would eliminate the
> race condition, but I don't think it's worth it to go down that road:
> 
>     lstat 
>     if regular file {
>     	    fd = open
>     	    fstat fd
>     	    if old inode != new inode {
>     		    warn
>     	    }
>     	    if regular file {
>     		    read for checksum
>     	    }
>     }
> 
> It's impossible to thwart a root user who wants to cripple a running
> process unless you're using a specialized kernel on specialized
> hardware, so I don't think it's worth making integrit slower by doing
> the two stats.
> 
> On the other hand, DOS attacks aside, you could say this as an
> opportunity to make integrit more robust.  e.g., What if a daemon
> replaces a regular file with a fifo right after our "lstat" and before
> "open"?  What do others think?  If there's interest I could implement
> the fstat technique and benchmark it.
> 
> -- 
> --Ed Cashin                    integrit file verification system
>   ec...@co...          http://integrit.sourceforge.net/
>