by redmail.netbsd.org with SMTP; 14 Mar 2000 23:17:33 -0000
	by myall.awadi.com.au (8.9.3/8.9.3) with SMTP id JAA13855;
	Wed, 15 Mar 2000 09:46:04 +1030 (CST)
	id JAA24889; Wed, 15 Mar 2000 09:46:01 +1030
	id JAA05668; Wed, 15 Mar 2000 09:46:01 +1030
From: blymn@baea.com.au (Brett Lymn)
Message-Id: <200003142316.JAA05668@mallee.awadi>
Subject: Re: Kernel modification that verifies execs against a md5 fingerprint
To: thorpej@zembu.com
Date: Wed, 15 Mar 2000 09:46:00 +1030 (CST)
Cc: blymn@baea.com.au (Brett Lymn), tech-security@netbsd.org
In-Reply-To: <20000314090204.N10872@dhcp0.wlan.shagadelic.org> from "Jason R Thorpe" at Mar 14, 2000 09:02:04 AM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

According to Jason R Thorpe:
>
>On Tue, Mar 14, 2000 at 01:36:46PM +1030, Brett Lymn wrote:
>
>	(1) Demand paging of executables is effectively dead with this
>	    modification.
>

Only with the first time you load the executable - this is where the
caching of the fingerprint status comes in.  The next time through the
cached comparison is used to you still get demand paging.  The status
is cached in the vnode so if the file gets modified the cached status
gets trashed automatically.

>	(2) What does it really buy you?  The md5 signatures are loaded
>	    at boot time, presumably from a file in the file system.
>	    What's to prevent an attacker from modifying this file?

It depends where you put the file.  I have been toying with the idea
of putting the file on the underlying mount point and modifying mount
to have a flag that would load the fingerprints when the filesystem is
mounted.  This way the file is inaccessible when the system is
running.  Where to put the fingerprints is an interesting issue.  As I
said the system is more a proof of concept, I am open to ideas to
improve the thing.

>	    That could cause a DoS (can't start programs!), or allow
>	    an attacker to sneak in a trojan horse.
>

Yes, you could have a DOS situation - would you prefer login logging
all your passwords to a file?

>	(3) To address (2), you'd need to make the file immutable.  But,
>	    for that matter, you could also make all executables on the
>	    system immutable, which would prevent people from changing them.
>

Making all the executables immutable is a pain in the butt and
difficult to audit properly.  By using a fingerprint the audit happens
automatically.

>And, now that I think about it, you could easily add a sysctl that could
>allow execution of programs only if they had the SCHG (system immutable
>flag -- only super-user can set/clear it) set,

OK but you cannot give someone a signed fingerprint file that they can
whack on their machine to give assurance that none of the binaries
(and maybe other files) have been tampered with.  It means you can
provide a level of assurance that cannot be given if you just check
file modes.

> and also hack in a list
>of valid interpreters that exec_script could use ... then you could e.g.
>chmod go-x the interpreter, and allow #!-style execution if the interpreter
>appeared in the kernel's list of valid interpreters.
>

OK but you cannot prevent someone running their own script with and
approved shell interpreter.  I can.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================