Re: medusa and others

From: Amon Ott <ao@rsbac.org>
Subject: Re: medusa and others
Date: Thu, 31 Aug 2000 10:43:08 +0200
Next Article (by Author): FF bug Amon Ott
Previous Article (by Author): Re: MAC trivial question... Amon Ott
Top of Thread: Re: medusa and others Fabrice MARIE
Articles sorted by: [Date] [Author] [Subject]
On Mit, 30 Aug 2000 Milan Pikula - WWW wrote:
> On Wed, 30 Aug 2000, Fabrice MARIE wrote:
> 
> W>> Yes, I also had a look at medusa and others. There are some good ideas in
> W>> them.
> W>> > from medusa:  you can set-up some bobby-traps. Say for example the user
> W>> > runs ifconfig, you can configure medusa to run exit or logout instead of
> W>> > ifconfig only for some users.
> W>> Currently, the request function does not return anything but the result.
> W>> You could of course include a pointer in the request, where the new path
> W>> could be stored. The problem is the request dispatching - all models must
> W>> be very careful not to change what other models put in there.
> W>> How about a simple extra model "booby-trap"? Still, the extra request
> W>> parameter would have to be included into the kernel patches for all kernel
> W>> versions.

[Snipped Medusa concept for size]

> If (in the concept of RSBAC) someone will change the dentry in the middle
> of desiding about what to do with the request, it will definately break the
> security model, unless the order of applied modules is known to the author
> of configuration - and unless he understands why it is so important. There
> is another possibility, which is somewhat hard to do on SMP machines: keep
> the "side effects" of decision modules appart and apply them after receiving
> information from all the decision modules. This should result in... working...
> implementation of file redirection in RSBAC.

> I'd like you to consider file redirection first, before turning to execution
> of scripts on request. We have many experience with this, as we choose the
> user-space way. One must be ABSOLUTELY sure, that the events, did by the
> executed script, wouldn't trigger the same trap again. With a "third-party
> software" (namely script interpreters) this is impossible. And, of course,
> one cannot rely on the result of such user-space software, because "we" are
> the kernel, the thing which CREATES some 'kernel-space' and 'user-space' on
> machine, so "we" cannot RELY on any user-space thing, which, in fact, we
> provide. There is an "art of doing user-space apps, which will not break
> something", which we had to learn first.

There is already an internal function rsbac_adf_request_int() with the
additional parameter of the module *not* to call.

So the redirection module could be the last module, only being called, if all
others have granted access to the original object. After redirection,
rsbac_adf_request_int would be called for a second chain of decision on the new
target, but without calling redirection again.

> Anyway, the concepts of Medusa and RSBAC are so close (with the little fact
> in mind, that RSBAC is implementing well-known security policies in the
> kernel, which is more "nice" and "fast", but less "versatile" and "portable"
>  (but this depends on the view point)), that I considered making the interface
> to call RSBAC decision modules as the 'plugin?' 'module?' to the kernel part
> of Medusa after kernel rewrite. At this time it's not on my immediate 'todo'
> list, because it feels a bit like a thievery; but some day it maybe will be
> nice, together with an RSBAC decision module, communicating with Constable.

It is never easy to let your child go its own way... ;)

RSBAC and Medusa are both interesting Open Source projects. A combination of
both will probably result in an even better solution, so let's do it.

An RSBAC plugin module (using REG) which calls your constable should not be
that difficult to do. We would have to figure out how to translate RSBAC
requests to Medusa interfaces. Some things will be difficult to do, but a
simple working version cannot be that far off.

On the other hand, the RSBAC decision interface is hardly ever changing, so just
go ahead and use the module code. The main problem will be providing the object
attributes the modules rely on. Maybe you could start with ACL, because this
one has its own independent data structures and does not use general attributes.

> PS: I am interested in anything related to both RSBAC and Medusa. Could you
> point me to some archive, where I can find this thread? Or simply forward
> me the preceding message to the one I am replying, please :)

You find the list archive at http://www.compuniverse.de/rsbac-archive.

Amon.
-
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.