On Sun, Aug 21, 2005 at 05:58:05PM +0200, Nino Dehne wrote:
> 
> I got the message for every entry that ultimately points to the same inode.
> /usr/sbin/zzz was just an example. One thing I notice is the different case
> of the algorithm name, if that matters.
> 

I just checked the code, no, that does not matter.  The mere fact you
are trying to add a fingerprint for a file that already has been added
triggers the message.  The message is just noise but maybe we should
mute it if the entry being added exactly matches what is there.

> 
> Thanks again. I didn't know veriexec caches this way.

The fingerprint result caching is one of the fundamental bits of
veriexec that permits it to operate with such a low impact on machine
performance.  Without caching you would see a 50% degradation in
machine performance.  Note, both positive and negative fingerprint
evaluations are cached - this prevents a denial of service attempt by
trying to run the same bad executable over and over again.

> Please note that
> I wasn't proposing checking just the path. What I was assuming was
> that the path adds to the uniqueness of a veriexec entry, i.e. an entry
> with the same inode and the same hash could still be tied to another
> criteria that it must match. So even if you removed the checksum from the
> checklist on subsequent checks due to caching, there would be 2 more
> things to check, inode and pathname.
> 

I won't say no immediately but doing this at first glance seems overly
complex and may open up a can of worms.

> Additionally, doesn't that mean that if I'm able to move a binary so
> that it ends up on the same inode, I could fool veriexec? 

No, not really, escpecially if the storage is under direct control of
the kernel (there are some tricks you can play with NFS and the like),
by this I mean a hard disk that the kernel has complete control over.
In this case trying to write to the inode is blocked (open for write
is checked in the vfs layer and blocked on fingerprinted files), mv
will unlink the old file and repoint the inode (fingerprint will fail
because not the same inode)... in fact a recent commit now prevents a
fingerprinted file from being moved aside.  Fingerprinted files are
not allowed to be removed.  I believe that we have our bases covered
given the assumption I stated above (and there is a way to even remove
the requirement of direct kernel control) but you can never be sure
with software....

>This is under
> the assumption that veriexec caches only the inode as known good and
> ignoring the supposed difficulty of that task. Could the caching be made
> optional? In my case - using NetBSD as a firewall/router - I could
> definitely live without it.
> 

Turning off caching would mean a big speed hit as every time a program
was exec'ed the hash has to be evaluated again.  I have not
benchmarked the newer hashes but when I tried this with md5 a kernel
build took 1.5 times longer when performing hashing every time when
compared to a non-veriexec run.  The concept of caching can be
disconcerting but as long as the other kernel security mechanisms work
then it is quite safe (modulo any bugs of course :)

-- 
Brett Lymn