[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Fri, 2006-02-03 at 09:27 -0500, Steve Grubb wrote:
> On Friday 03 February 2006 09:17, Stephen Smalley wrote:
> > > -F "se_sensitivity>=2" -F "se_sensitivity<=9"
> >
> > This requires that SELinux perform the filter interpretation, as the
> > context structures and dominance relation are purely internal to it, and
> > the audit system should not be directly tied to them.
> The plan was to call SE linux libraries to interpret custom text (public) to 
> sensitivity and send the raw sensitivity (s0).

Right, libsetrans.  But that still leaves you with a string that has no
inherent meaning or ordering.

>  As for dominance 
> calculations...we aren't granting access. If someone say they want s2 and 
> above, we should be able to see that s3 is greater than s2 and generate an 
> audit record. If you have an api for comparing s3 and s2, let us know and 
> we'll use it.

Nothing guarantees that s3 dominates s2; s2 _could_ dominate s3
depending on the policy specification.  In the SELinux security server,
the relevant functions are mls_level_eq (equivalent), mls_level_dom
(dominates), and mls_level_incomp (incomparable), but they act on the
internal structure representation (integer sensitivities and extensible
bitmap category sets), not the string format.  audit system needs to
call a SELinux API if it wants to compare two MLS levels.  

> I suppose you are right. I should have mentioned that we have no interest in 
> parsing the full context. User space was going to take the context parsed by 
> humans as separate fields. This way it is extensible. If a new extension is 
> added in the future, we add a new field.

That's fine.

> In kernel, Dustin was going to use your api to take sid to individual 
> components. For string we only need = and !=. For levels and sensitivity, we 
> were going to need to do a comparison since people could desire auditing 
> secret and above, but let everything else go.

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.   Then you pass a handle to that
precomputed context and the SID to the comparison API, and it returns
the relation (equivalent, dominates, dominatedby, incomparable).

Stephen Smalley
National Security Agency

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]