[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