On Mon, Aug 22, 2005 at 12:11:33AM +0930, Brett Lymn wrote:
> On Sun, Aug 21, 2005 at 02:05:58PM +0200, Nino Dehne wrote:
> > 
> > veriexec currently refuses to load valid entries with a message like
> > 
> > veriexec: Duplicate entry. [/usr/sbin/zzz, 4352:3223] old[type=0x01, \
> > algorithm=RMD160], new[type=0x01, algorithm=rmd160] (same fingerprint)
> 
> You should not see that message for that entry, that's a bug I think
> since the old and new are exactly the same.

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.


> > It appears that pathnames are not actually compared when looking
> > up an entry. This means any filesystem entry pointing to the same inode
> > as a currently stored entry is automatically valid. Is this an intended
> > effect?
> 
> Yes, that is the intended effect - when the fingerprints are entered
> into the kernel the path is resolved to a device/inode pair.  If an
> entry for that fingerprint already exists (as can happen when files
> are hardlinked) then the type and fingerprint algorithm are checked to
> ensure they don't conflict with the incumbent entry - this is to
> prevent someone accidentally putting what should be mutually exclusive
> attributes on a fingerprinted file (like trying to turn a DIRECT entry
> into a FILE entry - that would be bad).

Thanks for the explanation. Earlier I wasn't even aware that the path
printed in veriexec messages actually has only informational character.


> > Think shells offering a restricted mode by calling them via
> > r$SHELL.
> >
> 
> The problem is that the switching is done on ARGV[0], if someone can
> manage an exec with the right arguments then they can execute the
> "allowed" path but stuff in the "disallowed" application name in
> ARGV[0] and the binary will run, bypassing your lockdown.
> 
> (this totally leaves aside the issue of relying on restriced shells
> for any sort of lockdown)

Of course I don't use or propose the use of such means since I find
them dubious at best. I just wanted to give some feedback about my (wrong)
assumption of veriexec's operation.


> > Is the name of an executable really discardable in the context of a
> > mechanism like veriexec? Am I overlooking something?
> 
> path is not a reliable piece of information to keep ahold of.  If a
> something on a path is run once, veriexec will cache that the binary
> matched the fingerprint so is ok to run again without performing the
> secure hash of the disk contents again.  If someone then moved that
> binary away and put their own there on the same path then simply
> checking the path is the same will result in a trojan being run
> because the cache said it was ok.  We keep what uniquely identifies
> the executable on the storage and that cannot be tampered with
> (assuming all the other security measures are taken and, of course,
> modulo bugs).

Thanks again. I didn't know veriexec caches this way. 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.

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? 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.

Regards,

ND