[redhat-lspp] RBAC Roles

[Stephen Smalley]

On Mon, 2005-09-19 at 16:30 -0400, Steve Grubb wrote:
> 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.

Sure, you can define any number of roles.

> 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.

They can modify the security attributes (i.e. the types) of the objects
they own, in accordance with policy, and these types ultimately govern
what roles can access the objects (because the role must be authorized
for the domain, and the domain must be allowed access to the type).  I
don't know what a "role" would mean for an object; it seems
subject-specific in nature.  But you can certainly define what objects
are accessible to what roles. 

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

I don't think we have a specific utility for this purpose presently,
although the Tresys setools may allow you to get the same information.
It wouldn't be hard to create such a utility, but note that it will need
to change for the ongoing work to create a separate Linux user ->
{SELinux user, authorized range} mapping that will be used to avoid
having to modify the kernel policy when adding/removing/changing Linux
users.

> 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?

SELinux policy allows you to enable auditing (for the MAC checks) based
on the type (domain), so you can e.g. audit all operations by secadm_t.
Allowing the syscall audit filters to be enabled based on parts of the
security context would likely be helpful, but requires that the audit
subsystem invoke the security module (via new LSM hooks) to check the
filter since the audit subsystem doesn't directly have access to the
security context.

-- 
Stephen Smalley
National Security Agency