[redhat-lspp] RBAC Roles

[Steve Grubb]

On Tuesday 20 September 2005 07:47, Stephen Smalley wrote:
> 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.

OK. I guess what I'm looking for at this point is consensus as to whether or 
not to include it. I personally think we will benefit from doing this as a 
step towards MR should LSPP be sunset.

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

I guess we need to create a tool for it.

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

I don't think this is the right solution. Even though you can do that, I think 
that doesn't feel like using the audit system. While this solves the problem 
in one respect, I think it violates the spirit of the requirements. We need 
to consolidate this capability into the audit system. I suspect that if there 
was an audit system back when SE linux was being written, the audit system 
would have natively handled this. I also want to be able to do an auditctl -l 
to see all the rules that lead to audit events.

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

The audit system needs to get its hands on this info. We need to be able to 
write rules like: auditctl -a exit,always -F role=secadm_t

What I would like to do is have all the auditing control in the audit 
interface so that its easier to teach people in the future. I think it would 
be awkward to show them all the auditctl rules and then say oh by the way, if 
you need to audit a role, you have to go modify the policy. I don't think we 
want to go down that road.

-Steve