Re: RBAC with SELinux MCS

[Shaz <shazalive@xxxxxxxxx>]

On Wed, Jul 1, 2009 at 12:40 PM, Justin P. Mattock <justinmattock@xxxxxxxxx> wrote:

Shaz wrote:

On Wed, Jul 1, 2009 at 12:01 PM, Justin P. Mattock <justinmattock@xxxxxxxxx <mailto:justinmattock@xxxxxxxxx>> wrote:

   Shaz wrote:

       Dear list,

       I was studying some earlier work on RBAC and came across
       Kuhn98 [1], which says that RBAC can be implemented if some
       interface function is used to map privilege sets of RBAC with
       MCS. James Moris blog article on MCS [2] states that MCS is
       just dicretionary like DAC if hierarchies like of MLS levels
       are not used. It might be because of the implementation of
       current LSPP on Linux distros. So my question is that can RBAC
       be used with SELinux if the mapping function is provided?

       Some further literature or existing work being pointed out
       will be appreciated.

       Thank you.

       [1]
       http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/kuhn-98.pdf
       [2] http://james-morris.livejournal.com/5583.html

       --        Shaz

   Im guessing the mapping function is "newrole" right!
   if then yeah you should be able too i.g.
   newrole -r  *_r -- -c /usr/bin/* (or wherever/whatever your
   wanting to use in that role).
   might get complicated with the sensitivity
   levels and categories(that is if you really tweak them).


Is this consistent with NIST RBAC standard to a greater extent? Never use roles in SELinux because thought it was just grouping of users.



   Justin P. Mattock




--
Shaz

It should be of standard to NIST(if not then they should fix that)
I don't see it as grouping users(but could be wrong),
I see it as a way of confining the situation i.g.
if  you run an application in certain role, it's confined to
that role and only the privileges that role provides.

Those privileges depend on the kind of object defined by the "class" and enforced by the object manager. I think its making sense to my stupid mind now :) I will appreciate if someone can clear out if this is consistent with the NIST standards.

Thanks Justin.
 

Justin P. Mattock

-- 
Shaz