Date: 21 Aug 2003 01:34:14 +0530
From: Balwinder Singh <balwinder@....net>
To: bugtraq@...urityfocus.com
Subject: Re: Need help. Proof of concept 100% security.


Hi All,

I thank to all those who helped me and replied to my request.
Fumes, advice, guidance everything is welcome.
Please accept my appologies for delay in reply.

1. Please note this is an effort by an indivisual. I am working
on it for last two years. There are going to be cirtain things 
which I don't know OR even don't understand. I have tested the
system myself and found acceptable, but had no other way to have
experts advice. So I had to put up 203.197.88.14.

2. Various people have pointed me to various links and comparing EFC.
I will quote following from EFC docs at 203.197.88.14/efc

"We do not claim that this is the only technology providing guaranteed  
security, there could be (should be) more methods aiming 100% security.
EFC is just one	of those methods.
This is first release. Please note that we do not claim that right from
version EFC will provide 100% security (although it can) against all
kind of attacks.Future releases will achieve higher level of security
leading to unbreakable system"

3. Results of EFC are in front of you all. There have been 2000+ plus
attacks, still system is up and running without a reboot. All
applications are doing what they are supposed to do. All these
security loopholes and attacks have cost money in past.

--------------------------------------------------------------------

Let me describe main components of EFC here. Some components described
here will be described fully in future docs. Some people adviced me to
check for existing patents, if they clash with EFC. Well I am confused
what to do if that turns out to be true. At that same time I would like
to mention that I am not going to file any patents for any of concepts
described hereafter. So if somebody finds something interesting and
wants to implement in his own way is free to do so.

1. EFC is not a kernel patch it is module. The decesion weather to make
patch or module was tough one. A patch can even guard against kernel
flaws. But M$ showed the way, Some functionalities can sacrificed for
users ease. 
How I added struct efc to struct task_struct from a module is another
debatable issue.

2. EFC has following components.

 2.1. Tool to generate behavior model automatically: I will quote
 following from EFC docs.

"A database can be generated for selected programs. One can even select
all programs in a system to generate database. This model is based on
system calls a program can make during its run time. Forks by a program
are also considered. This model is generated from binary of the program,
source code is not needed. Thus model can be generated for commercial
programs as well which do not supply source code.
To generate database program is run on the system. Now all 
possible capabilities of the program are used in order to generate
database. If you do not want to use full capabilities of the program
just dont use them during database generation. For example when
generating database for ftpd you may chose only to download files.
In this case only downloads will be allowed the moment upload
is tried ftpd will die."

Any part of code which was not a activated during data base generation
will not be allowed at actual run. If I want to use that part of the
code I must create conditions needed to activate that part of code.

"May be some day law should make it compulsory for manufacturer to
supply behavioral model of his software in some standard format leading
to accurate database. The moment this happens most of security related
issues will vanish, given that we have perfect software to implement
model based control"

This will also discourage those who put back doors in their software,
as back doors can be detected by analyzing behavior model automatically.

2.3 Execution Flow Control (EFC): The moment request for execution of a
program is made, kernel also loads program's behavioral model into the
memory. Each request by a program is compared with model data base. If
request agrees with model it is permitted otherwise program is killed,
fact is logged, system administration is alerted and diagnosis are
started to find	out the reason for violation. Currently EFC kills
program and logs an error message in system logs, starting diagnosis
part remains to be done.
With EFC all attacks which rely on stack corruption, binary image
modification can be avoided.

2.2 Making libpam to talk with kernel: The programs like sshd, ftpd etc
allow outside people come in, these program act as gates to the system,
I call call these programs GATES (not to be confused with a billionare).
I call libpam as GATEKEEPER.
Cirtain code of these programs must get activated only after
aunthetication. As soon as one logs in fact is communicated to kernel.
Kernel takes care of changing UID of resulting process, plus other
security measures. 
EFC comes with modified libpam and a new syscall to register a user with
kernel. This syscall can only be called by libpam no other program can
call it.

2.3 Kernel based aunthetication: As of today it is a user process which
does aunthetication. But here kernel does not trust root as well. Any
operation which you think is important can be auntheticated by kernel.
Apart from behaviour model, EFC supports a rule base looking something
like this

open /var/www/html/* /usr/sbin/httpd

The rule says only /usr/sbin/httpd is allowed to open /var/www/html/*.
You can implement as many rules as you please.

As soon as some other process tries to open /var/www/html, kernel
prompts for aunthetication. A successful aunthetication will disable
that rule for five minutes. Every five minutes all ruled renabled.

--------------------------------------------------------------------

In need of comments

Balwinder

--------------------------------------------------------------------

Powered by blists - more mailing lists