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

[Ed L C. <ec...@co...>]

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/