[redhat-lspp] RBAC Roles

[Stephen Smalley]

On Tue, 2005-09-20 at 08:57 -0400, Steve Grubb wrote:
> 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.

What precisely do you want to control?   The kernel crypto API isn't
exposed to userspace presently, right?  IPSEC configuration might be of
interest, but not clear that we have the right granularity of access
control presently.  

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

I understand the reasoning here, but as a counterpoint, note that the
SELinux audit rules keep the policy-related information (e.g. types)
encapsulated within the policy.  And the SELinux policy is the natural
point to specify auditing of SELinux permission checks.  The audit
subsystem was designed to cooperate with/complement the security
subsystem's native ability to audit object accesses rather than to
replace it.

> 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

Adding improved ability to the audit system to specify context (and
context components) on its filters is fine with me, but:
- I don't think it obsoletes the use of SELinux's native auditing of its
MAC permission checks,
- The context and context components need to ultimately be interpreted
by SELinux, because the audit subsystem has no direct knowledge of
policy components or even the ability to directly look at a security
context within the kernel (security fields are opaque outside of the
security module).

auditctl could certainly pass down the string "role=secadm_r" to the
kernel audit subsystem, which could then pass it along to SELinux (via
LSM hook), which could encode it into a rule understood by SELinux and
returned as a callback to the audit subsystem, and the audit subsystem
could later invoke that callback when checking audit filters to allow
SELinux to evaluate the rule on the particular opertion.

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

If you want to enable syscall auditing for a given role, then doing so
via auditctl is quite reasonable.  But for the SELinux permission check
auditing, it really has to be handled by SELinux.

-- 
Stephen Smalley
National Security Agency