From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steve Grubb <sgrubb@redhat.com>
Subject: Re: [PATCH v4] selinux: support deferred mapping of contexts
Date: Wed, 7 May 2008 12:48:12 -0400
Message-ID: <200805071248.13439.sgrubb@redhat.com>
References: <1210002195.25678.678.camel@moss-spartans.epoch.ncsc.mil>
	<1210173806.6434.84.camel@moss-spartans.epoch.ncsc.mil>
	<7e0fb38c0805070829q1bda9233h1f71865634776e71@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Return-path: <linux-audit-bounces@redhat.com>
In-Reply-To: <7e0fb38c0805070829q1bda9233h1f71865634776e71@mail.gmail.com>
Content-Disposition: inline
List-Unsubscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: linux-audit@redhat.com
Cc: Eric Paris <eparis@parisplace.org>, James Morris <jmorris@namei.org>, selinux@tycho.nsa.gov
List-Id: linux-audit@redhat.com

On Wednesday 07 May 2008 11:29:36 Eric Paris wrote:
> On Wed, May 7, 2008 at 11:23 AM, Stephen Smalley <sds@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.

-Steve