[PATCH 1/2] SELinux Context Label based audit filtering

[Stephen Smalley]

On Fri, 2006-02-03 at 09:47 -0500, Steve Grubb wrote:
> On Friday 03 February 2006 09:46, Stephen Smalley wrote:
> > Ok, so this means that SELinux needs to provide an API for such
> > comparisons, and likely for precomputing the internal context structure
> > for a given MLS range provided in an audit rule so that we don't have to
> > re-do that on each filter evaluation. 
> 
> What if the filter rule was:
> 
> auditctl -a exit,always -S open -F "se_sensitivity>=confidential"
> 
> And that is all you have to work with? Are we still OK?

First, you'd need a way to indicate whether you mean the low (also
referred to as current) level or the high (also referred to as clearance
or max) level in the above specification, as each security context has
two levels associated with it (they show up abbreviated as a single
level if they happen to be the same), a low and a high.

Given that distinction, the way I see this as working is as follows:
1) the above auditctl command is invoked by the user,
2) auditctl calls libsetrans to map the string "confidential" to the
string "s1",
3) auditctl constructs a filter rule specifying the above filter,
including the "s1" still as a string, and passes it to the kernel audit
system,
4) the kernel audit system passes the "s1" string to a new in-kernel API
for SELinux that returns a void* handle to a precomputed mls level
structure (likely augmented with policy serial number to detect
invalidation due to policy reload) dynamically allocated at the time the
filter rule is inserted,
5) the kernel audit system saves this handle in its internal form of the
filter rule for later use upon filter evaluation/checking,
6) the kernel audit system harvests SIDs as needed during syscall
processing for the current task and objects referenced during the
syscall and saves them off in audit context,
7) upon filter evaluation/checking, the kernel audit system passes the
void* handle saved in the rule and the desired SID to a new in-kernel
API for SELinux that applies the MLS dominance computation and returns
one of (equivalent, dominates, dominatedby, or incomparable).
8) the audit system checks whether the returned relation matches the one
specified in the filter (here, >= is the same as dominates).
9) If so, the audit system then asks for contexts for the relevant SIDs
and adds them to the audit message.  This might be an issue btw as we
might run into an allocation failure at this point.

We would also need a callback registered by the audit system to be
called by SELinux upon policy reload to re-compute all of the
precomputed MLS level structures saved in audit filters against the new
policy.

-- 
Stephen Smalley
National Security Agency