Re: Feature request for 1.2 (or for 2.0)


From: Amon Ott <ao@rsbac.org>
Subject: Re: Feature request for 1.2 (or for 2.0)
Date: Thu, 29 Mar 2001 10:57:33 +0200

Next Article (by Author): Re: Re[2]: RSBAC v1.1.1 problem Amon Ott
Previous Article (by Author): Re: two questions about ACL. Amon Ott
Top of Thread: Feature request for 1.2 (or for 2.0) janos.milus@dataware.debis.hu
Next in Thread: Re: Feature request for 1.2 (or for 2.0) janos.milus@dataware.debis.hu
Articles sorted by: [Date] [Author] [Subject]


On Don, 29 Mär 2001 janos.milus@dataware.debis.hu wrote:
> There is a very usefull function in the Trusted Solaris and in the Medusa.
> It is called "redirection". That means, if a subject want to access an
> object, it may access an other object (the decision module change the real
> target to a fake). As I see in the current architecture it is almost
> impossible to write a decision module wich for example opens the /etc/joke
> file when you want to open the /etc/passwd.

It was a design goal that this is impossible.
 
> What do you think, it is possible to add to the RSBAC "roadmap"  the
> "redirection" support?

We already had this discussed some time ago. The problem is that it will break
some assumptions of the architecture:

- All modules are independent:
  - Once you change the target, when will what module decide about which
target? This could be solved by changing the target after a full run and then
rerun the decision.
  - How do we handle conflicts: One module wants this replacement, another
that. Which one is chosen? How is the unused replacement data cleaned up and
notified to its module?

- No internal kernel variables are ever changed by decision, except return
values.

- All programs should work without changes. What if a program writes to
/etc/passwd and another one has to read this info?

So redirection would have to be very carefully designed. I fear there is no
clean way that does not lead to new conflicts.

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

Next Article (by Author): Re: Re[2]: RSBAC v1.1.1 problem Amon Ott
Previous Article (by Author): Re: two questions about ACL. Amon Ott
Top of Thread: Feature request for 1.2 (or for 2.0) janos.milus@dataware.debis.hu
Next in Thread: Re: Feature request for 1.2 (or for 2.0) janos.milus@dataware.debis.hu
Articles sorted by: [Date] [Author] [Subject]


Go to Compuniverse LWGate Home Page.