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: Fri, 30 Mar 2001 08:06:58 +0200

Next Article (by Subject): file access auditing johnston@megaepic.com
Previous Article (by Subject): Re: Feature request for 1.2 (or for 2.0) janos.milus@dataware.debis.hu
Top of Thread: 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:
> > It is even a bit more complicated: If access is to be redirected, the
> original
> > target will not be touched at all. What do we do, if another module
> denies
> > access to this file - do we just take the second (rerun) result, or deny
> access?
> >
> > Taking the last result only is probably the best way.
> 
> It is just a brainstorm:
> As I know (but I may wrong) there is a list wich contains pointers to the
> registered decision modules. If there is a system call, you go through this
> list and call the modules. The modules says GRANTED, NOT_GRANTED,
> DO_NOT_CARE,
> etc. If there is just one NOT_GRANTED return, the access is not granted.
> I may wrong, but in this case the remain of the list is not called.

This is wrong, they all get called. In older versions, only a previous result
UNDEFINED could stop calling.

> Make a new return value: REDIRECT, that redirects the target and rerun the
> decision circle. If the security officer could change the order of the
> list,

Security Officer is a concept of only one model. However, we could have a
request type for that and let all modules decide.

> he could decide when he want to make redirection: first, last, or somewhere
> in the middle. It solve the conflict between redirection modules, too. Of
> course,
> the order of modules must be store in the filesystem, becouse in the next
> boot
> it must remain the same. If new module registered, it goes to the end of
> the list.
> (dreams, sweat dreams...)

I have a different idea: We make a complete run through all modules and collect
all redirection wishes. Then we decide what (if any) redirection is made,
change the target and restart at the beginning. A redirection priority setting
at module registration time (with a fixed medium value for existing fixed
modules) could be used for that.

Let's keep up the important principle that all modules are independent and
that the order of modules must never change the result.

Another problem that just comes up: If redirection is optional, we must
tell the registering modules whether or not they are allowed to redirect - they
might have been compiled separately.

This could be a return value at registration time, or an extra function
boolean rsbac_reg_may_redirect(void);
We could even make redirection switchable at runtime.

> > Well... I try to keep things simple. Just remember when you first tried
> to use
> > RSBAC, how did you feel?
> >
> 
> ;) RSBAC was the 4th rule-based (mandantory) access control in the u*x
> world
> what I see. The first was a little bit confusing at first time,
> of course. But there was no suprise in RSBAC.
> 
> As I see in the rule-based access control systems there is 2 important
> things:
> (1) How deeply math-based, how fine there materialize a theoretical models
>     (for example the medusa is too ad-hoc, it is easy to make covered
>      channel in it. In thit point the RSBAC is one of the bests)
> (2) How easy to integrate it to the production system. In this scale the
>     medusa is better than the RSBAC. (I speak about the Bell-LaPadula
> module,
>     becouse the other RSBAC modules don't control the information
> streaming,
>     just the information access.)

This is not really true - e.g. we have RC ipc types, with
default_ipc_create_type on roles. This can easily be used to separate
information streams.

ACL could be extended to individual IPC object ACLs.

>     The HALO model implemented in medusa much easily integrated to the
> production
>     systems. The redirection may change this order without change the
> previous.

While being a good marketing argument, the Bell-LaPadula model in my opinion is
not suited for the Linux environment. If you are looking for a model
combination that is designed for Linux use, take AUTH, RC, FF and ACL.

I myself use AUTH and RC, with the odd FF flag somewhere, mostly
no_rename_or_delete on /home etc. I never needed ACL so far, but I have no
users with shell access on my servers.

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.