Subject: Re: verified executables
To: vishal butte <vishal_butte@yahoo.co.in>
From: Brett Lymn <blymn@baesystems.com.au>
List: tech-security
Date: 01/26/2006 22:25:47
On Wed, Jan 25, 2006 at 01:00:08PM +0000, vishal butte wrote:
> 

>   Where can i find the source code for the Verified Exec ? (
>complete kernel source in which Verified exec is implemented ). So
>its the BIG problem for me to understand how its implemened in the
>kernel .
>

The code is in the NetBSD kernel sources.  Most of the code is in
kern_verifiedexec.c.
    
>    
>   1) How the database is maintained ? Whether a regular file is used or database is maintained using RDBMS ? 
>    

flat file.

>   2) If regular file is maintained then whether the records in the file are arranged using AVL tree / B+ tree? Or new records just simply appended to file ?
>    

the file is not order dependent - it is used as the source to load the
in-kernel hash tables.

>   3) As i read , it is supposed to be used on the servers. So i want
>   to know that, if only root administrator can add the hash of the
>   file to the database then the users those having access to the
>   server should go to administrator every time if they want their
>   executable in the database ?

not just servers it can any style of machine, only root can load new
file fingerprints and loading can only be done before the strict level
is raised.  Once strict is raised new fingerprints may not be added.
Due to the pain in the ass factor I would not recommend using veriexec
on a general purpose workstation where new applications are being
built and/or run unless you leave strict at the "warn only" setting
and sieve through the warnings yourself... not a recommended set up.

>   4) Is that right that hash is calculated on the contents of the
>   file? or some another parameter is used for calculating hash like
>   inode no. and modification time of the file ?

only the contents of the file.

>   5) How security level is maintained ? If the server is rebooted
>   then whether it starts in strict level 0 or in the the level which
>   was before rebooting ?  If it starts in previous level then where
>   this information abt the previous level is maintained ?

when the kernel boots strict level will be 0, the fingerprints get
loaded and the strict level may be raised after that during the normal
boot process.

>   6) Its said that in strict level 2 "...along with level 1, It will
>   deny write access and prevent the removal of monitored file..".
>   So is that means you ( root ) can remove the files from database
>   in level 1.  Then Why its not allowed in strict level 2..Or i am
>   misinterpreting it?  >

You are misinterpreting.  The removal referenced there is the removal
of the file from the file system, this is to prevent an attacker
removing a file with the FILE flag and replacing it with their own
version.

>   7) Whats the use of the flags..?
>

The provide extra information to the veriexec kernel subsystem that
affect how it treats the fingerprinted file.
    
>   8) How root administrator will come to know whether a particular
>   file is already present in the database or not? Are u maintaining
>   any flag ?

Well, the find functionality of your favourite editor can help.  You
would get a warning if you try to load a fingerprint with differing
flags.

>   eg.  if " ls -l " command is used then that will show you file
>permissions along with some added flag say " V " which says the
>particular file is in the database? like that anything? If not then
>thats a good idea..!!! ( may be )

There are no indications as to whether or not a file is in the
in-kernel hash tables.  Making such a change would be fairly intrusive
to the stat structure.  Also, it does mean that an attacker would be
able to simply determine if a file is protected or not... at the
moment that is difficult to determine and finding out would leave log
traces.

>   9) if in level 0 , any file can be tampered then how the file that contains the database is secured?
>    

The bootstrap issue is a difficult one to solve properly - at the
moment it relies on the fact that level 0 access should only be
available to someone physically at the console.

-- 
Brett Lymn