Re: medusa and others

From: Milan Pikula - WWW <www@banan.napri.sk>
Subject: Re: medusa and others
Date: Wed, 30 Aug 2000 16:10:40 +0200 (CEST)
Next Article (by Date): Re: medusa and others Amon Ott
Previous Article (by Date): Re: medusa and others Fabrice MARIE
Top of Thread: Re: medusa and others Fabrice MARIE
Next in Thread: Re: medusa and others Amon Ott
Articles sorted by: [Date] [Author] [Subject]
Hi,

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.

I think this wouldn't be good: the idea behind Medusa is slightly
different: Medusa offers its own security model, in which each security
relevant action is considered by (in this order):
	* vs-concept (our own in-kernel security policy; one and ONLY one)
	* in-kernel cache
	* user-space daemon (which interpretes the commands of our
	  programming language, thus enables you to programm the exact
	  security model/policy to satisfy your needs).

Ability to REDIRECT files (not only at the execution time: one can have
different /etc/shadow for various services or situations) is only a side
effect of this design: we have only ONE in-kernel change, so if someone
tries to access the file, it's easy to throw the question to the user-space
and resolve an dentry from the request.

We wanted to put as much as possible to the user-space mainly because of
posibilities, which user-space offers, the comfort, portability and
flexibility of this design (we can replace the authorisation daemon with
something which sends packets over network, and the Constable can run on
another box not directly connected to the inet, nor running Linux). This is
why the simultaneous applying of various security models can be done in
user-space - one level above the layer which enables this change.

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.

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.

	Milan

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 :)

--
Milan Pikula, WWW. Finger me for Geek Code.
http://fornax.elf.stuba.sk/~www, www@fornax.elf.stuba.sk
.. dajte mi pevnu linku a pohnem zemegulou ..




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