On Mon, Nov 04, 2002 at 11:03:13PM +1030, Brett Lymn wrote:
> On Mon, Nov 04, 2002 at 12:39:01AM -0500, Thor Lancelot Simon wrote:
> > 
> > No, you don't get a guarantee of that -- not unless you know that
> > each and every last bit of code involved in doing the notification
> > is valid as well.
> >
> 
> Technically, that is not an insurmountable thing - drop safe logging
> box monitoring the console output (the violations are kernel printf's)
> would do the job.  I think that a bit extreme but not infeasible.

The solution you propose doesn't actually solve the problem I state; the
problem for the attacker simply becomes ensuring that the wrong, or no,
console output is generated -- something he can almost surely do if he
has compromised the system sufficiently to do things like bypass
filesystem write restrictions.

> Boot from cdrom, validate the fingerprint list against the disk media,
> load the fingerprints remount the now validated hard disk and go for
> it.  If you fingerprint the files they will not be allowed to be

That is sufficient -- at boot time.  It is not sufficient at runtime;
you have no guarantee that the code you fingerprinted at boot time is
what actually gets run when you, the user, request that executable _X_
be started.  An attacker who's compromised the memory protection of the
kernel -- which is, essentially, what he'd have to do to overwrite an
immutable file, change your fingerprints, etc. -- can arrange for whatever
code he cares to to be what runs, not just what you validated on boot.

> I know, you are proposing a total and utter breach of the kernel's
> control over the hardware and then telling me what I have done is bad
> because it cannot prevent that any more than the existing security
> mechanisms can.  I find it hard to comprehend how that can be used as
> an argument for not doing what I have done.

My point is, in essence, that since the kernel is a single protection
domain, there is nothing _but_ "a total and utter breach".  If you are
in a position to subvert the kernel's enforcement of read-only
filesystem semantics, you are _also_ in a position to run arbitrary
evil code while continuing to happily output stored fingerprints into
a log file or on the console each time "the correct code" is invoked.
Actual runtime validation that's really worth anything is _hard_.
Outputting some diagnostic messages that claim that validation is
actually occurring and that the system is unmodified does not prove
anything at all except that the running system image printed some
stuff on the console; if you think that constitutes "assurance" as
you defined it, you would appear to me to have a false sense of security.

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud