|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Crispin Cowan (crispin
WIREX.COM)Date: Wed Mar 28 2001 - 18:56:12 CST
Ron DuFresne wrote:
> sounds very simliar to the things claimed about CA-associates<?> entrust
> kernel tool. That tools comes with a cost, is my understanding, a
> preformance hit, depending upon how much 'is asked' of it.
I just went fishing on Entrust's site, and it seems to be mostly about certificate
management stuff. The only parts of Immunix that relate to certificates are
CryptoMark (Kurt's correct, it's not released yet) and that you should be keeping
your private keys on a secure host, e.g. an Immunix machine :-)
> How do these
> immunix kernel enhancements fair up to resource utilization when tasked up
> some?
StackGuard has nearly no overhead, as measured with Webstone against a
StackGuard-protected Apache http://immunix.org/StackGuard/performance.html
SubDomain has at worst 2% overhead, again measured with Webstone against a
SubDomain-confined mod_perl script running under Apache (try that with chroot :-)
There's no web doc yet on the performance tests, but they're in this paper
http://immunix.org/subdomain.pdf that we presented at LISA 2000
http://www.usenix.org/events/lisa2000/
FormatGuard http://immunix.org/formatguard.html only impacts printf performance.
Good luck trying to find a printf-bound test application :-) Our best guess for that
was man2html, which showed a 1.3% performance overhead. Most programs should
experience significantly less overhead. Paper to appear at USENIX Security
http://www.usenix.org/events/sec01/
RaceGuard imposes a substantial overhead of 104% on stat() calls probing for
non-existant files, and a modest 13% overhead on fork() system calls. For macro
performance testing we used the Khernelstone :-) test of build the Linux kernel from
source (lots of stat'ing, temp files, and forking). Global overhead was well under
1%. Another paper to appear at USENIX Security http://www.usenix.org/events/sec01/
Crispin
>
>
> Thanks,
>
> Ron DuFresne
>
> On Sun, 25 Mar 2001, Kurt Seifried wrote:
>
> > ImmunixOS and SecureWave are working on stuff (SecureEXE is shipping actually,
> > nice product) to prevent trojan code/etc.
> >
> > http://www.securityportal.com/closet/closet20010314.html
> >
> > RaceGuard/CryptoMark
> > Last but not least, we have RaceGuard and CryptoMark. As far as I know, neither
> > has been released yet. However, RaceGuard is planned for the next release of
> > ImmunixOS. Crispin Cowan (CTO at WireX) had this to say:
> >
> > It's a kernel enhancement that makes mktemp (and hand-rolled variations) safe to
> > use. In the StackGuard tradition, it detects attempts to race the victim suid
> > root program in progress, and (optionally) either refuses the killer open()
> > call, or kills the victim process. I've been running it on my laptop for a
> > month, and there's a few teething problems, but it basically works. It will be
> > in Immunix 7.1.
> >
> > CryptoMark is a sort of tripwire-style program, except that it operates in real
> > time (remarkably similar to SecureExe in description). If it is released and
> > works as advertised, it will not only prevent Trojans from running, but will
> > help prevent users from running unauthorized programs.
> >
> > http://www.securityportal.com/closet/closet20010307.html
> >
> > Preventing Trojans and Restricting What Users Can Run
> > One of the easiest ways to hack into a system is to have a batch file that
> > creates a new administrator account, and get someone with administrative access
> > to run it (just one reason why auditing and logging system events is so
> > important).
> >
> > This can be as simple as creating a desktop icon and telling the help desk,
> > "every time I click on this I get a weird error." They come by, log in, run it,
> > and presto, the batch file (or whatever Trojan) is run.
> >
> > In addition, most companies want to control what users run. This is typically
> > done by using system policies; however, these are very weak. Unless you give the
> > full path to the executable, all an attacker needs to do is name their program
> > "notepad.exe" (or something else the user is allowed to run). Even with the full
> > path name to the executable, an attacker can overwrite a program the user is
> > allowed to run with a Trojan - and this doesn't even touch on the problems with
> > other kinds of executable content such as DLLs.
> >
> > The SecureExe system uses not only the name and path of the program or file in
> > question, but a SHA-1 digital signature, stored on a server. The system uses a
> > kernel module that intercepts calls to things like DLLs, makes sure that the
> > user in question is allowed to run the item, and that the signature matches. If
> > the signature doesn't match, it won't be run and the violation will be logged.
> >
> > This is useful not only for preventing people from running Trojans (accidentally
> > or otherwise), but also for enforcing software versions. (If someone upgrades,
> > it will "break" since the signatures do not match the old profile.)
> >
> > Kurt Seifried, seifried
securityportal.com
> > Securityportal - your focal point for security on the 'net
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Cutting the space budget really restores my faith in humanity. It
> eliminates dreams, goals, and ideals and lets us get straight to the
> business of hate, debauchery, and self-annihilation." -- Johnny Hart
> ***testing, only testing, and damn good at it too!***
>
> OK, so you're a Ph.D. Just don't touch anything.
If you say so :-)
-- Crispin Cowan, Ph.D. Chief Research Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]