role based audit filtering

[Stephen Smalley]

On Tue, 2005-12-06 at 17:13 -0600, Dustin Kirkland wrote:
> The userspace interface might look something like the following, to
> filter out messages related to the sysadmin_r role:
> auditctl -a entry,always -S open -F role=sysadmin_r

nit:  sysadm_r

> My questions revolve around translating a role string such as
> "sysadmin_r" to something that can be easily matched in the kernel.  
> 
> - What are going to be the best practices here?  
> 
> - Is it possible for either userspace, or the kernel upon adding the
> rule to translate a valid role to some string based id that can be
> compared later?

If you want to map the role to an integer index that can be compared,
you need to do that in the kernel.  The SELinux security server does
maintain such indices for the individual context components, but doesn't
presently export them outside of the security server (not even to the
rest of the SELinux module, which only deals with SIDs that are indices
to complete contexts, not individual fields).  If the security server
starts exporting those indices to the audit system, then we also need to
deal with consistency there, so a policy reload would have to trigger a
re-mapping of the original role strings to the correct index in the new
policy (and the new policy may no longer define that role at all, at
which point you have to invalidate the entire filter in some way).

> - And speaking of "later", when is going to be the best time to do this
> comparison?  I'm thinking perhaps of adding the necessary fields to
> struct audit_context such that audit_filter_rules() only another case is
> needed to do the comparison and match the role.  Is that a good place
> for this?
> 
> - I would expect to be crucified if I attempted to do strcmp() or
> strstr() string comparisons/matches in the kernel at the oft-called
> filters, so I'm really hoping to keep this to integer comparisons.  For
> that, I think I might need an api into SELinux to get some sort of
> integer looking value to compare.  Am I approaching this correctly?

I'm not clear on whether this is a legitimate assumption, especially
given the existing overhead already imposed for syscall auditing.  But
let's think about what information we have available at the point of
comparison:
- the SID of the task (within SELinux only, not directly exported to the
audit system), and
- the role information in the audit filter role (either string or
integer index).

The audit system could ask SELinux via a new interface for the role
value (string or index) corresponding to the current task, and compare
that value (string or index) with the one in the filter.

-- 
Stephen Smalley
National Security Agency