Re: medusa and others

From: Fabrice MARIE <fabrice@celestix.com>
Subject: Re: medusa and others
Date: Wed, 30 Aug 2000 17:00:51 +0800

Next Article (by Subject): Re: medusa and others Milan Pikula - WWW
Previous Article (by Subject): man under debian potato "Attila Szabo"
Next in Thread: Re: medusa and others Milan Pikula - WWW
Articles sorted by: [Date] [Author] [Subject]

Hi !

> Yes, I also had a look at medusa and others. There are some good ideas in
> them.
> > from medusa:  you can set-up some bobby-traps. Say for example the user
> > runs ifconfig, you can configure medusa to run exit or logout instead of
> > ifconfig only for some users.
> Currently, the request function does not return anything but the result.
> You could of course include a pointer in the request, where the new path
> could be stored. The problem is the request dispatching - all models must
> be very careful not to change what other models put in there.
> How about a simple extra model "booby-trap"? Still, the extra request
> parameter would have to be included into the kernel patches for all kernel
> versions.

This thing would be useful to run a program (or a script) exept of what the user wanted.
Imagine someone hacked into your box (even though you made a fortress) by anyway.
Now he tries to run ifconfig to bring down your network. If you put a boobytrap on ifconfig
here you can force the program alert-security-admin.pl who would send you an
SMS for example. I mean this feature would enable an action (whatever it is) to be taken instead
of what the user thought. Done properly, this example would make the script kiddy that his script
worked and therefore he will stop.

> > Very strict policies are one thing, having some fun with script-kiddies
> > is
> interesting as well. > Seriously, most of the script kiddies would stop
> attacking you if you bother them a bit on your system. >
> Is this not just a bit of fun play? I would rather not run anything for
> them on my secured system - they might find a hole in the other program as
> well. Nothing against a playground on another system in the DMZ, but this
> is rather a network and firewall issue.

I get totally what you mean. But what I was saying is to add this ON TOP of your
traditionnal strict policy driven security. Just as a precaution :)

> > openwall:  they have a patch to have a non-executable stack, the patch
> > does
> other stuff as well... > does it work nicely with rsbac ? Have anyone used
> those patches ? Is it configurable extensively (like rsbac is) ? > I'm
> thinking that it would be nice to add those feature in rsbac .. not at all
> to replace rsbac with these toys. >  > What do you think ?
> non-exec stack should not interfere with RSBAC, but I never tested it.

Ok ... I'll try this one with rsbac :)

Thanks again for everything.
Fabrice.
-- 

-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.