[redhat-lspp] RBAC Roles

Steve Grubb sgrubb at redhat.com
Fri Sep 23 21:04:35 UTC 2005


On Friday 23 September 2005 16:33, Stephen Smalley wrote:
> To clarify, I think we need to focus on making incremental improvements
> to what exists to meet the actual requirements, not completely
> overhauling what exists to meet wishlist features.

What wishlist? If you are referring to the "auditing under lspp" mail, lets 
discuss those under that thread.

> I further disagree with moving the auditallow/dontaudit functionality from
> SELinux policy into auditctl and the audit subsystem.

I don't think anyone ever suggested moving the functionality. Out of 
curiosity, what is the basis of your objection to allowing auditing via the 
audit system?

> - enhancing SELinux policy to support auditallow/dontaudit rules based
> on levels (if that is truly required; need to look further at the actual
> requirement and whether we can't do this based on type as I'm not sure
> why anyone would be suppressing auditing entirely on _all_ objects with
> a given level - seems like the wrong granularity),

This is not in the requirements. The question I posed on the "auditing under 
lspp" thread is whether or not this capability should exist. No one has 
commented either way on the list I posted.

> - creating new utilities and front-ends to enable easier configuration
> of SELinux audit rules without requiring policy sources and making the
> binary policy regeneration and reload transparent to the user,

Binary policy regeneration means the audit rules are persistent. That's way 
more invasive than what I was looking at.

> I can also see the desirability of allowing syscall audit filters based
> on context components (e.g. role, type, level), but I'm not entirely
> convinced it is truly _required_ (versus entire contexts),

The only ones that are called out in the specs are context labels, roles, and 
net addresses. Everything else in my list is up for debate.

-Steve 




More information about the redhat-lspp mailing list