Message-ID: <2e6ab3f9266037e311f91fbd42d96970e1904eec.camel@ieee.org>
Subject: Re: [PATCH] New interface to dontaudit access to cert_t
From:   Chris PeBenito <pebenito@ieee.org>
To:     "Sugar, David" <dsugar@tresys.com>,
        "selinux-refpolicy@vger.kernel.org" 
        <selinux-refpolicy@vger.kernel.org>
Date:   Tue, 19 Feb 2019 19:33:21 -0800
In-Reply-To: <2e4ccece-4ca3-37fa-f76c-97d37e2f5534@tresys.com>
References: <20190212130456.11572-1-dsugar@tresys.com>
         <8982046d-990a-29f5-6d76-d202ce647845@ieee.org>
         <e74efb79-5354-a997-cce1-c82b82b2c699@tresys.com>
         <4563f4e3-7525-f19c-55a6-45caca5786f7@ieee.org>
         <2e4ccece-4ca3-37fa-f76c-97d37e2f5534@tresys.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

On Sun, 2019-02-17 at 16:34 +0000, Sugar, David wrote:
> 
> On 2/16/19 2:40 PM, Chris PeBenito wrote:
> > On 2/14/19 8:56 AM, Sugar, David wrote:
> > > 
> > > On 2/13/19 6:42 PM, Chris PeBenito wrote:
> > > > On 2/12/19 8:05 AM, Sugar, David wrote:
> > > > > I'm seeing a bunch of denials for various processes (some
> > > > > refpolicy
> > > > > domains, some my own application domains) attempting to
> > > > > access
> > > > > /etc/pki.  They seem to be working OK even with the denial. 
> > > > > Adding
> > > > > interface to dontaudit this stuff and calling the interface.
> > > > > 
> > > > > type=AVC msg=audit(1549932300.668:266): avc:  denied  {
> > > > > search } for
> > > > > pid=7077 comm="X" name="pki" dev="dm-1" ino=138
> > > > > scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023
> > > > > tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
> > > > > type=AVC msg=audit(1549932306.553:430): avc:  denied  {
> > > > > search } for
> > > > > pid=7345 comm="clamd" name="pki" dev="dm-1" ino=138
> > > > > scontext=system_u:system_r:clamd_t:s0:c1
> > > > > tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
> > > > 
> > > > My guess is there is some common library between them (maybe
> > > > glibc)
> > > > which is triggering this.  It seems like this might potentially
> > > > cover up
> > > > legitimate access.  It's just hard to tell by just dir
> > > > searches.
> > > > 
> > > 
> > > Digging into this I have found a few things, and please note that
> > > I am
> > > not seeing this denial in permissive.
> > > 
> > > Looking at strace for clamd I see an attempt to open the (non-
> > > existent)
> > > file /etc/pki/tls/legacy-settings.  I think this would explain
> > > the
> > > denial on dir search.
> > > 
> > > If I create that file (even empty) labeled cert_t I see denials
> > > (in
> > > permissive) for clamd_t cert_t:file { getattr open read }.
> > > 
> > > audit2allow suggests the boolean 'authlogin_nsswitch_use_ldap'
> > > should
> > > resolve the issue (for clamd_t).  This makes sense as clamd uses
> > > the
> > > interface auth_use_nsswitch(clamd_t).
> > > 
> > > So, assuming that I don't want to enable
> > > 'authlogin_nsswitch_use_ldap'
> > > is there a way to quiet this denial?
> > 
> > The dontaudit could go in the else block for that tunable.
> > 
> That works for me.  In this case though, should I leave the interface
> as 
> proposed before or would it be more preferable to don't audit access
> to 
> cert_t files along with directories?

The latter is preferable.

-- 
Chris PeBenito