[redhat-lspp] RBAC Roles

[Steve Grubb]

On Tuesday 20 September 2005 09:24, Stephen Smalley 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?

That was in a previous mail...Anything that inits the crypto, changing any of 
its params, algorithm modes, and selection of the algorithm would require 
Crypto Admin role. This could involve several files. I think sshd & stunnel 
are the common apps in Security Targets. There are probably 3rd party apps 
that would want this as well. The point is to be able to audit by that role 
or search the logs by that role.

> The kernel crypto API isn't exposed to userspace presently, right?

Not sure. I think James might be more familiar with this.

> IPSEC configuration might be of interest, but not clear that we have the
> right granularity of access control presently.

True.

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

Which is bad. There are 2 places that control auditing. We really don't want 
people tweeking policy if its avoidable.

> And the SELinux policy is the natural point to specify auditing of SELinux
> permission checks.

I think this is a bad way to do it. When someone asks the admin where did this 
message come from, they will have to auditctl -l and grep through policy 
files to figure that out. Also, you can't add a audit rule without compiling 
and reloading policy can you? Changing the policy is an auditable event, 
loading the policy is too. This adds 2 event when only 1 was needed. What if 
the policy is not on that machine or maybe the policy compiler was removed 
for security?

> The audit  subsystem was designed to cooperate with/complement the security
> subsystem's native ability to audit object accesses rather than to
> replace it.

I don't think we want to replace it. I think we want it to share a lot of the 
same kernel infrastructure. The rule gets loaded by auditctl and sent into 
the SE Linux subsystem for evaluation.

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

I think the audit system needs to be able to interface with SE Linux code. To 
add audit rules, list audit rules, and delete audit rules.

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

Right. I agree. I think auditctl -a exit,always -F role=secadm_t would go into 
SE Linux for evaluation. The audit framework does not necessarily need to do 
the actual audit event generation. That can come from SE Linux.

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

Right. This is along the lines of what I'm thinking. Callback would probably 
not be necessary. The message will arrive in the filter after audit_log_end() 
and we can do any additional filtering there.

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

Agreed. I guess we should work out these details. We need an API. Dustin 
submitted a patch to add label support and I think we need to make some 
changes to the patch. We also need an API to list what's inserted and to 
delete audit rules from SE Linux.

-Steve