[rsbac] Resources and Enhanced Role Compatibility

Amon Ott rsbac@rsbac.org
Mon Oct 28 09:39:01 2002


On Saturday, 26. October 2002 17:24, Jörg Lübbert wrote:
> Meanwhile, a subject having many roles would still be great and quiet
> easy to implement if the rights of every single role are added to the
> final set of a subjects rights (instead of a user having to switch
> between the single roles).

RC deliberately has single roles for subjects only. This avoids all the 
problems with mutual exclusive roles for separation of duty (including 
uncontrolled flow of information) and keeps the model simpler.

My paper for the NordSec conference next week discusses this in a comparison 
to RBAC and DTE models. It will be published on rsbac.org after the 
conference. I already got people saying that RC model is too complex, so I 
will be very slow in adding more options.

> My suggestion about resource control via RSBAC is still valid btw ;)
> It'd be great to control cpu time, memory and max open files via RSBACs
> RC and ACL module.

For me, resource control does not fit well into these models. However, it can 
be easily fitted into the CAP module, similar to the existing min and max 
values for capabilities.

RC and ACL can already be used to prevent changes to existing limits through 
the SCD rlimit target, but I agree that this is not sufficient.
 
> And I also had the idea that it would be nice to have Type groups
> instead of only the types (which gets a bit out of control if you have
> many types for different purposes and often add and delete types). It'd
> be really great and easy to maintain if you could have something like
> that in RSBAC...

Again, it would make the model even more complex. Are you thinking of a type 
hierarchy, where rights to master types are inherited to subtypes as well? 

This would be very powerful, but you would have to consider the whole 
hierarchy whenever you wanted to adjust rights to an object. Currently, you 
just consider the role and the effective type.

Amon.
--
http://www.rsbac.org