[rsbac] ACL changes proposition

[Amon Ott]

On Mittwoch, 1. September 2004 21:23, Michal Purzynski wrote:
> i would like to propose small change in ACL
> for now having rule disalowing user from accesing some object it 
does not
> mean that he will not be able to access it, because of inheritance 
rules.
> why not change ACL is such a way, that if there is no access rule
> for subject to object, inheritance will step in (like it is now 
<correct
> me>) but in case if we have this rule inheritance would not be taken 
into
> account ?
> so as an example:
> 
> user badcracker1 does not have any rules determinating his access to 
file
> topsecret1, so ACL calculates them from inheritance
> 
> but...
> 
> if we have rule (dis)allowing access to topsecret file by user 
badhacker1
> this rule is the _one_ and the _only_ rule determining his access to 
that
> object, without inheritance.
> 
> so generaly rule that is most tight gives out finally answer about 
access
> 
> it should be adopted to all of ACL subjects of course

We could have an option, which does not use inherited group or role 
rights, if a user has an explicit ACL entry. However, this already 
creates a problem with RC forced roles for daemons: In that case, we 
want the role to be significant, not the user. As ACL administration 
should be as group based as possible, returning to user entries is 
not optimal.

Now let's consider that an explicit group ACL entry stops inheritance 
for all group members: Then adding or removing a group member can 
change the member's effective rights in an inconsistent way: User 
based rights become dependent on group memberships.

So generally, I consider this idea as not ideal and would rather not 
make the change.
 
> second thing (i am not conviced to it as i am to previous idea)
> 
> if subject has access to /dir/file it is required to for him to have
> search (get_status_data also ?) access to /dir
> this way it can not get information about /dir content, but one 
could
> 'poke' to gues what it contains.
> here my idea goes...
> 
> if subject has access to /dir/file and not to /dir it _can_ go 
throught
> /dir but only to /dir/file and not anything else in this dir.

This is the meaning of SEARCH: You can go through the dir to a file. 
There is already a to-do list item to require SEARCH right on a file 
to be able to see it, which should do most of what you are looking 
for.

It might make administration a bit more complicated, but 
implementation much easier: Lookup is a loop, which walks through the 
path from top dir to the file.
Now, how should we determine the file's attributes to know if SEARCH 
should be allowed, if we have not yet looked it up? We would have to 
change the whole RSBAC logic for lookups from dir-by-dir to the 
result only, and let the kernel cleanup all structures, if we deny 
the lookup after all work has been done.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde geschreddert...
Dateiname   : nicht verf?gbar
Dateityp    : application/pgp-signature
Dateigr??e  : 189 bytes
Beschreibung: signature
URL         : http://www.rsbac.org/pipermail/rsbac/attachments/20040917/e3cb2452/attachment.bin