Re: Upcoming 1.1.1 changes

From: Amon Ott <ao@rsbac.org>
Subject: Re: Upcoming 1.1.1 changes
Date: Fri, 5 Jan 2001 09:48:52 +0100

Next Article (by Author): Re: patch-2.4.0-prerelease-v1.1.0 is uploaded Amon Ott
Previous Article (by Author): new r-tools in /pre dir Amon Ott
Top of Thread: Upcoming 1.1.1 changes Amon Ott
Next in Thread: Re: Upcoming 1.1.1 changes "john huttley"
Articles sorted by: [Date] [Author] [Subject]

On Don, 04 Jan 2001 John Huttley wrote:
> ----- Original Message -----
> From: Amon Ott <ao@rsbac.org>
> To: RSBAC List <rsbac@compuniverse.de>
> Sent: Friday, 5 January 2001 01:09
> Subject: Upcoming 1.1.1 changes
> > 1.1.1-pre1 is getting into shape now.
> >
> > Other wishes?
> >
> 
> Yes.
> 
> The semantics of the FF module are confusing.
> 
> It ought to be one of the simplest models, but I cant figure it out.
> 
> Firstly there is the naming of attributes as "only".
> 
> This implies exclusivity. It is logically impossible to have two attributes named
> "only" active
> at the same time. If they could be applied simultaneously then they can't be
> "only" can they??

No, the naming means 'grant only this type of access'.

> Secondly there is the nature of the default flags.
> The default seems to be no flags, which permits all access.
> The flags (excepting secure delete and inherit) should then be defined as "deny"
> flags.
> 
> EG: read_deny, write_deny, execute_deny, search_deny.
> These can be combined logically without any semantic problems.

This is just another viewpoint.

> (what happens if you put execute_only and no_execute flags on together?)

FF is restrictive, so both flags are applied: One says, you can only execute,
the other says, you can not execute. The result is no access at all.

This is Unix after all: You are perfectly free to shoot into your own foot. ;)

Maybe the menu tools should be more explicit.

> Thirdly,  the interaction between inherited and explicit needs to expanded.
> Either to have an inherit mask or to have tri-state flags (on, off, inherit)

Tristate could be a useful expansion. However, the current idea is a
two-state-model:

1. add_inherited is set: apply explicit flags *and* add inherited ones
2. add_inherited is not set: apply explicit flags only

On inheritance, only the valid flags directly above count.

> Are you familiar with the Netware Flags? (as against trustees)

I have worked with Netware 3.11 to 4.1 for several years - thus the ACL model.

> That is a pretty good model.

I will have a look - my Netware experience is a bit rusty by now. FF is partly
inspired by Netware, but I found my set of flags more useful then.

> Probably a lot of work, but something to think about for the future.

Probably not really much - the FF_flags attribute is there, and the FF
infrastructure, too.

I will first update the model description in modules.htm to make the behaviour
clearer.

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.