[PATCH v4] selinux: support deferred mapping of contexts

Stephen Smalley sds at tycho.nsa.gov
Wed May 7 17:20:42 UTC 2008


On Wed, 2008-05-07 at 12:48 -0400, Steve Grubb wrote:
> On Wednesday 07 May 2008 11:29:36 Eric Paris wrote:
> > On Wed, May 7, 2008 at 11:23 AM, Stephen Smalley <sds at tycho.nsa.gov> wrote:
> > >  On Wed, 2008-05-07 at 11:17 -0400, Eric Paris wrote:
> > >  > >  I assume we do NOT want to use this variant interface when getting
> > >  > >  contexts to display in audit messages, as we want the audit
> > >  > > messages to correspond to the actual denial and to yield proper
> > >  > > policy if turned into an allow rule.
> > >  >
> > >  > Is there any way we could get them both displayed if there is a
> > >  > denial?  Might be interesting to know both that the denial was
> > >  > actually unlabeled_t object but also what the 'incorrect' label
> > >  > was.....
> > >
> > >  Easy to do kernel-side, but requires a new avc audit field that won't
> > >  cause any complaints by audit userland or tools like audit2allow.
> 
> What would be the proposed name of this new field? Would it hold just a 
> context string? FWIW, audit user land doesn't really care except that we 
> don't have name collisions on fields.

If we did this (not part of my current patch, but can be done as a
follow-on), then we'd need to define two new fields, one to correspond
to the real/raw context string corresponding to the scontext and one to
correspond to the real/raw context string corresponding to the tcontext.
And they would only be present if the scontext and/or tcontext happened
to be invalid under current policy.  Maybe "rscontext" and "rtcontext"
if we don't think that will confuse existing userspace
(audit2allow/sepolgen, setroubleshoot, seaudit, ...).
   
-- 
Stephen Smalley
National Security Agency




More information about the Linux-audit mailing list