[redhat-lspp] RBACPP requirement question

[Klaus Weidner]

On Mon, Jun 05, 2006 at 12:10:46PM -0400, Linda Knippers wrote:
> 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?

This is a followup to the discussion about this during the 2006-06-05
conf call.

One way to deal with the role definition requirements would be to take
advantage of the modular policy and permit admins to define new roles,
with certain restrictions:

- The shipped policy source files must not be edited, in particular it's
  essential that the MLS constraints remain unmodified.
  
- The shipped roles (sysadm_r etc.) must not be modified. If you want a
  different type of sysadm role, create a new role (which may be based on
  sysadm_r, possibly using inheritance/dominance) and assign users to
  that role. If you don't like the original sysadm_r definition, just
  don't use that role, but don't modify it. Use your own role instead.

It's based on the assumption that the TE allow rules and constraints are
orthogonal mechanisms, and as long as you keep the MLS constraints intact
they will stay effective and enforce the appropriate restrictions. Of
course, you can give MLS override capabilities to new roles, but that
still means that the MLS constraints are doing their job since the
constraints also contain the rules for overrides.

I'm not entirely sure yet how well this would work in real life. An
interesting example would be using a new module to define a "backupadm_r"
that has DAC/MAC read overrides but no write overrides. I'm not very
familiar with the policy tools so this would take me some time to figure
out, if one of the gurus could give a quick example that would be much
appreciated.

Open issues:

- I expect that audit records will be at the level of "admin A loaded a new
  policy" with no details about what got changed. The RBAC PP doesn't
  actually require specific details about the change to role data though,
  so I think it would be ok to keep it at that level.

- Is it ok with Red Hat if customers make such modifications, and still
  have their systems remain in support? Obviously RH can't be responsible
  if the new roles don't work right, but I think with the restrictions
  there should be high confidence that the additions shouldn't break
  anything that doesn't use the new roles.

Please comment if you have opinions about handling roles, especially from
an end user point of view.

-Klaus