Re: Can anybody check this out
From: bal (balwinder@gmx.net)
Date: 04/12/03
- Next message: Liam Cunningham: "Re: unix passwords"
- Previous message: Alex: "Re: Can anybody check this out"
- In reply to: Alex: "Re: Can anybody check this out"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: balwinder@gmx.net (bal) Date: 12 Apr 2003 01:02:09 -0700
"Alex" <alex.ferguson@NOSPAMdartmouth.edu> wrote in message news:<20030410175233.75988121.alex.ferguson@NOSPAMdartmouth.edu>...
> On 10 Apr 2003 19:08:31 GMT
> nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>
> > In article <6851e510.0304100945.299e30b@posting.google.com>,
> > Rajkumar <rkadam@hotvoice.com> wrote:
> > >
> > >I came across a paper which promises 100% security for Linux OS. They claim
> > >100% protection against
> > >1. virus
> > >2. worms
> > >3. Trojaned software
> > >4. Program flow modification (such as using buffer overflows)
> > >I wonder if such a protection can be provided?
> > >Full paper is located at www.trustedmachines.com/efc
> > >
> > >The concept looks interesting, but i am not able to understand how a Kernel level
> > >model can provide protection against all the above claims that the author makes.
> >
> > Does it also promise to restore your youth and make you irresistably
> > attractive to the opposite (and even the same) sex?
>
> My thoughts. My brief look at the site suggests that they are
restricting programs to certain sets of system calls, much as systrace
(see http://systrace.org) does. You typically generate systrace
policies interactively but this setup does it automatically as in
'systrace -A'. The latter approach doesn't allow you some of the
flexibility that systrace does, e.g. restricting arguments to execve
or filenames for filesystem accesses. Now, this efc business implies
some sort of 'behavioral model' which might or might not be more than
just a set of allowed system calls. If it's smarter than just a set
of syscalls, I'm interested to some degree. For now, I'll stick to
systrace.
>
> At any rate, neither efc nor systrace is going to protect you from an exploit which causes the targeted program to do something not-too-suspicious, for some not-that-intelligent interpretation of not-too-suspicious.
Well fumes and suggestions all are welcomed.
Once again I will stress(as told in paper) that, this is an effort
towards achieving higher levels of security. We donot at all claim
that right from version 1 EFC will provide 100% security. But we do
believe in future OSs will be intelligent enough to provide higher
level of security.
I have been trying to put an machine with EFC on the web for last six
months. Hope soon we may have a machine with EFC on net. Please do not
do anything silly with trustedmachines.com as it is not at all in my
control. I have hired just a small amount of space with (my) ISP.
I will try to summaries EFC as follows.
1. EFC can monitor syscalls with arguments. It creates a file in
/var/efc/complete_path_of_program. This text file can be edited to
include custom changes or to include wild card *. Execve is also
monitored.
This model is enforced at run time of program. Any syscall not allowed
or syscall with wrong arguments is denied and that process is killed.
2. EFC is linked with PAM library. We believe PAM is software
gatekeeper. We have modified pam lib to enable it to talk to EFC. This
helps in programs such as sshd (we call such programs as GATES as they
allow one to come in). Now when sshd auntheticates a user a efc knows
about it. A flag is set indicating that the process being EFCed has
been auntheticated. This flag enables syscalls which sshd can call
after aunthetication (such as executing a shell). If this flag is not
set and sshd tries to execute a shell it is denied.
3. Kernel aunthetication of desired actions. Apart from indivisual
program database a common policy written in a file can be implemented.
This file can contain actions which must be auntheticated by kernel eg
modifying /etc/shadow (OR /etc/*). In normal case kernel will check id
bit and decide what to do with request. But with EFC whenever such
action is required kernel will prompt for root (or whatever user is
configured) passwd if passwd supplied is OK, particular rule is
disabled and sysadmin can carry out desired task and again must
re-enable the rule. Note in this method admin has to run program twice
as first intance will be diverted for aunthetication only second
instance will do the required job.
4. Now if kernel space is overflowed EFC maynot help.
5. EFC cannot protect against denial of service attacks.
As told suggestions/fumes all are welcomed. I definetly need
suggestions and advice.
Regards
bal
--------------------------------------------------------------------------
CLOSELY WATCH NATURE, YOUR PROJECTS WILL SUCCEED.
- Next message: Liam Cunningham: "Re: unix passwords"
- Previous message: Alex: "Re: Can anybody check this out"
- In reply to: Alex: "Re: Can anybody check this out"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]