[redhat-lspp] RBAC Roles

[Stephen Smalley]

On Wed, 2005-09-21 at 15:54 -0400, Steve Grubb wrote:
> What if the system admin decided they do not want any records for host 
> 192.168.1.1 and they put in a suppression rule for that host id since RBAC 
> says this is legal. If they see records for that host, would we not be 
> meeting RBAC specs?

I don't know about the specs, but one could certainly provide a utility
that adjusts auditallow and/or dontaudit rules in SELinux policy without
touching the rest of it.  Without requiring policy sources.  And then
create a front-end wrapper for both this utility and auditctl so that
the admin can view it as a single config logically.

> Good point. As long as we have everything in ancillary records, I think we'll 
> be OK. I am wanting to reorganize the audit message generation so that SE 
> Linux doesn't call audit_log_format, but calls another function that takes 
> the data in binary form. This should help us to pick the right one. I really 
> don't see how we can meet requirements and have performance unless we get the 
> data in binary form. Audit events already stored off the context would have 
> to be re-parsed since they are text and that is ugly.

The issue is that on a single syscall, you might collect data on a large
number of inodes (e.g. every directory in the path plus the final
component, multiple paths to a single syscall like link or rename, etc),
so selecting the proper context to use for the filter evaluation may be
complicated.  Much easier if your filter rules are being applied on the
individual object accesses (i.e. LSM/SELinux hooks) rather than on
syscall exit, as with the SELinux auditing rules.  With regard to binary
format, I'm not sure what you plan to do about contexts, as we don't
provide a stable binary representation of them to userspace presently,
and doing so in a way that is policy-flexible and extensible isn't
entirely trivial.

-- 
Stephen Smalley
National Security Agency