From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Paris" Subject: Re: [PATCH v4] selinux: support deferred mapping of contexts Date: Wed, 7 May 2008 11:29:36 -0400 Message-ID: <7e0fb38c0805070829q1bda9233h1f71865634776e71@mail.gmail.com> References: <1210002195.25678.678.camel@moss-spartans.epoch.ncsc.mil> <1210088427.25678.771.camel@moss-spartans.epoch.ncsc.mil> <1210105048.25678.799.camel@moss-spartans.epoch.ncsc.mil> <1210164325.6434.22.camel@moss-spartans.epoch.ncsc.mil> <7e0fb38c0805070817h72ac3ce7k24dc38b7eaf0ec24@mail.gmail.com> <1210173806.6434.84.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m47FTlcw026350 for ; Wed, 7 May 2008 11:29:47 -0400 Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m47FTaZP026799 for ; Wed, 7 May 2008 11:29:36 -0400 Received: by wf-out-1314.google.com with SMTP id 25so293386wfc.6 for ; Wed, 07 May 2008 08:29:36 -0700 (PDT) In-Reply-To: <1210173806.6434.84.camel@moss-spartans.epoch.ncsc.mil> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Stephen Smalley , linux-audit@redhat.com Cc: James Morris , selinux@tycho.nsa.gov List-Id: linux-audit@redhat.com On Wed, May 7, 2008 at 11:23 AM, Stephen Smalley 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. Well, I'm not concerned about audit userland, if they can't handle arbitrary users or the audit subsystem that's an audit failure. As to audit2allow I'm clueless but I guess i could take a look if others think it is an interesting piece of knowledge... -Eric