On Fri, 2006-02-03 at 10:14 -0500, Stephen Smalley wrote:
On Fri, 2006-02-03 at 10:12 -0500, Stephen Smalley wrote:
> 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.
The other missing distinction above is whether you are referring to the
process sensitivity or the sensitivity of one of the objects accessed
during the syscall, e.g. the file context.
And where it becomes even more fun is when multiple objects are accessed
during the syscall, e.g. during path lookup you'll harvest one object
context or SID per path component. So is the above filter supposed to
be applied to just the terminal component or all of them?
--
Stephen Smalley
National Security Agency