[redhat-lspp] RBAC Roles

Steve Grubb sgrubb at redhat.com
Mon Sep 19 20:30:30 UTC 2005


On Monday 19 September 2005 16:10, Stephen Smalley wrote:
> Under strict policy, it is common to have to do a newrole -r sysadm_r to
> assume administrative privileges even when you are root.  Dan introduced
> a start at further creating a secadm_r role, although more work would be
> needed to properly decompose administrative responsibilities.

I also think there should be a crypto admin role. This would be used for 
anything that inits the crypto systems, changing any of its params, algorithm 
modes, and/or selection of the algorithm.

> Roles are just process attributes; files are always just "object_r".

I think to claim RBAC, don't we need to let users specify roles for their 
objects? FMT_MSA 1.1 seems to say that the users have the ability to modify 
the security attributes of objects they own.

> The role acts as an abstraction for grouping sets of domains for
> assignment to users and bounding the set of reachable domains.  Whereas
> traditional RBAC would speak of authorizing roles directly for
> permissions to objects, we would speak of authorizing roles for domains,
> and then authorizing domains for access to types.  That provides
> finer-grained control, including the ability to distinguish programs
> (based on their domain) within a single role.

OK. 

RBAC also calls out the ability to let users see all the roles they are 
authorized for. Does this currently exist? 

RBAC also requires that you can place audits based on a role. Would we expect 
to be able to use just secadm_r to make an audit rule or would we need to 
specify the whole context string?

-Steve




More information about the redhat-lspp mailing list