Message-ID: <20030815091448.A6451@lava.net>
Date: Fri, 15 Aug 2003 09:14:49 -1000
From: Clifton Royston <cliftonr@...a.net>
To: Balwinder Singh <balwinder@....net>
Subject: Re: Need help. Proof of concept 100% security.


On Mon, Aug 18, 2003 at 08:54:54PM +0530, Balwinder Singh wrote:
> I have developed an application, which I believe can provide 100%
> security against various attacks.I can hear people laughing. Hmm..

  It's not a new idea, FWIW.  I've certainly heard of this kind of
thing before.  That doesn't mean it's inherently bad, but you don't
provide any evidence that you've addressed the fundamental weakness in
the concept, or are even aware of it.  

  The general weakness is that a system which "learns" the expected
behavior of software and then enforces it will then prohibit correct
but *unexpected* behavior, as opposed to wrong behavior.

> Brief Introduction of EFC
> -------------------------
> 
> 1. Kernel runs in kernel space, which cannot be modified by user space
> programs. Each request from program ends up calling a routine in kernel
> space called syscall. Lets call syscall with arguments just syscalls
> 
> Each program will make a defind set of syscalls to achieve its
> objective. Now idea is to watch syscalls that a program is supposed to
> make during its run time. A database which describes the syscalls that a
> program can make is called behavior model of the program. Lets assume we
> can generate a behavior model which perfectly describes an application.

* This assumption is the weak point in the whole plan.

> Now any deviation from behavior model of program essentially indicates
> an intrusion at real time. Thus a corrective action can be taken. This
> makes kernel intelligent which knows which program should do what,
> rather than a slave of program in which any program can ask anything and
> kernel will provide it.

  Consider this thought experiment: Assume you rotate your webserver
logs once a month, and have the usual system-dependent procedure to do
this (something along the lines of "apachectl graceful" or "apachectl
restart" in your /etc/monthly.local file, for a BSD-style config.) You
run your behavior monitor on the webserver for two weeks, and it learns
that the particular sequence of syscalls associated with closing the
logs, shutting down the children, and restarting them, "never happens". 
Now at the end of the month when you run the log rotation, your web
server is killed as suffering from a security violation.  Oops.

  This is a trivial example.  The general problem in abstract form is
that unless you have a system for forcing an application to generate a
trace of all possible execution paths, in particular those for dealing
with exceptional conditions, there is a high likelihood that you will
be interrupting and preventing valid execution paths, hence
implementing your own "denial of service" on the system.  Software
quality testers will be aware what a difficult problem this is.  Your
description of your test doesn't mention whether you are evaluating
that half of the problem as well, but it doesn't sound like it.

  As often reiterated, the challenge of implementing secure computer
systems is not to make them secure; that can be done by disconnecting
them from the network, turning them off, and sealing them in a buried
vault.  The challenge is to make them secure while they continue to
operate "normally".

  All comments IMHO
  -- Clifton

-- 
     Clifton Royston  --  LavaNet Systems Architect --  cliftonr@...a.net

Did you ever fly a kite in bed?  Did you ever walk with ten cats on your head?
  Did you ever milk this kind of cow?  Well we can do it.  We know how.
If you never did, you should.  These things are fun, and fun is good.
                                                                 -- Dr. Seuss

Powered by blists - more mailing lists