[redhat-lspp] RBAC Roles

[Steve Grubb]

On Wednesday 21 September 2005 15:41, Stephen Smalley wrote:
> One caveat to keep in mind is that avc_audit also audits some permission
> checks that don't occur in syscall context (e.g. network input
> processing, SIGIO delivery), so you'd need to distinguish those cases
> and still have avc_audit directly emit audit messages for them.

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?

> Another issue here is that the audit filters are applied at the end of
> the operation, so any filtering based on _object_ level (versus process
> level) may be complicated.  You don't have the object anymore, and you
> have the aggregation of data for all objects accessed during the
> syscall.  With the patch from Dustin/Dan, you will have the object
> security context strings saved in the audit context, but you still have
> to pick the "right" one, split out its parts, and compare strings or map
> to a value.

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.

-Steve