On Thursday 02 February 2006 16:47, Dustin Kirkland wrote:
Other (less expensive option) for both the object contexts and the
task
context would be to instead only harvest the SIDs (via new interfaces) and
to provide interfaces for getting specific fields and compare them rather
than having to allocate memory and generate full contexts each time, as
we've discussed before on the list. That does require changes to the
SELinux module and new interfaces from it, of course.
Stephen, It might be better if you make an interface for Dustin and send the
patch. We can then apply it locally for testing.
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -140,6 +140,11 @@
> > #define AUDIT_PERS 10
> > #define AUDIT_ARCH 11
> > #define AUDIT_MSGTYPE 12
> > +#define AUDIT_SE_USER 13 /* security label user */
> > +#define AUDIT_SE_ROLE 14 /* security label role */
> > +#define AUDIT_SE_TYPE 15 /* security label type */
> > +#define AUDIT_SE_CAT 16 /* security label category */
> > +#define AUDIT_SE_SENS 17 /* security label sensitivity */
>
> There can be two levels in the MLS field (a low and a high), so you have
> potentially two sensitivities and two category sets, plus you may want
> to match on a particular category in a category set, not the entire
> thing.
I think we are covered. I mentioned to Dustin that those fields need to be
handled as integers for comparison. We should be able to specify a range for
matching like:
-F "se_sensitivity>=2" -F "se_sensitivity<=9"
> Also, the above doesn't seem very extensible to cope with
> potential future extension of the SELinux security context.
Is there a convention for context parsing? If not, we should probably decide
what it will be or at least how to identify the end of what we know so that
if they get out of sync in the future, it would do the wrong thing.
-Steve