[redhat-lspp] RBACPP requirement question

Linda Knippers linda.knippers at hp.com
Mon Jun 5 16:10:46 UTC 2006


Regarding this requirement on George's notdone requirement list:

> 28  	Useful role definitions

> Define a useful set of roles in the MLS policy. The admin roles
> should be separated. Consider including a crypto admin role. Ensure
> each override is accessible through at least one role.

> Red Hat added role separation to MLS policy with input from TCS.
> However, because the policy must be static in the evaluated config,
> the user admin tool will be used to assign roles to users.

> Now we have sysadm and audadm. Additional flexibility exists with
> policy modules, including overrides. Need to document role assignment
> procedure.

> selinux list  	90  	Wilson, George  	IBM

And this in his done list:

> 29  	Management of users and roles in flat file

> Create command line tools to manage and audit users and roles in flat
> file separated from base MLS policy. Actions need to be audited,
> which is covered in a separate task.  	

> Red Hat has been working on flat file user and roles implementation.  	

> Red Hat posted user and roles in flat files documentation. Tools
> need to be  created and instrumented with audit hooks.  	

> Red Hat mlsutils package  	100 Walsh, Dan  	Red Hat

What exactly can an administrator do with roles?  It looks like semanage
allows the admin to assign roles to SELinux users and to assign Linux
users to SELinux users but it doesn't allow an administrator to create
a role or to modify what an existing role is allowed to do.  Do I
understand that correctly?

If so, is this sufficient for meeting the RBACPP?  The PP isn't very
clear but FAU_GEN.1.1 talks about auditing the creation and deletion
of roles, as well as the assignment and deletion of privileges to/from
roles.  FMT_MTD.1 talks about being able to restrict to certain roles
the ability to modify and create role definitions and role attributes,
role hierarchies and constraints among role relationships.  Do the
audit and restriction requirements only apply if we provide the
ability for the admin to create and modify roles?

I looked at the TSOL ST and it doesn't seem to include the ability
for the admin to create new roles, although I think the TSOL product
can actually do it.

If we do need to provide the ability to create and modify roles,
any ideas on how best to do that?

-- ljk




More information about the redhat-lspp mailing list