[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