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.

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

Before you ask, no, paths cannot really be added as they are not
useful - in reality all the hardlinked paths point to the same inode
so making the distinction based on path makes no real sense.

> What comes to mind are binaries that act differently depending on the
> name they are called with. Say I have files A and B, hardlinked to the
> same inode. I want to allow execution of A but not B. Currently that's
> impossible.

Yes, that is correct.  About the only work around I can offer is that
you break the link and have two copies of the binary - not ideal but
it would work.

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

-- 
Brett Lymn