Received-SPF: pass (google.com: best guess record for domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: another memlockd patch
To:     Russell Coker <russell@coker.com.au>,
        Dominick Grift <dominick.grift@defensec.nl>
Cc:     selinux-refpolicy@vger.kernel.org
References: <20200410060317.GB35896@xev> <ypjl369bn4ku.fsf@defensec.nl>
 <1765247.TeHuJhGoBa@liv>
From:   Chris PeBenito <pebenito@ieee.org>
Message-ID: <62d460c9-c538-7abd-aa7e-822ea9d22139@ieee.org>
Date:   Tue, 14 Apr 2020 11:04:46 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <1765247.TeHuJhGoBa@liv>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

On 4/10/20 5:40 AM, Russell Coker wrote:
> On Friday, 10 April 2020 6:10:57 PM AEST Dominick Grift wrote:
>>> +allow memlockd_t self:unix_dgram_socket { create connect };
>>
>> the unix dgram socket creating is probably redundant and implied with
>> logging_send_logs_msg() as journald uses dgram_sendto for logging?
> 
> You are correct, that is redundant.  Chris shall I submit the patch again or
> would it be easier to just delete that line when you merge?

Please resubmit with below change too.

>>> +# cache /etc/shadow too
>>> +auth_read_shadow(memlockd_t)
>>
>> Hmm since /etc/shadow is mode 000, how is memlock able to read this
>> without cap_dac_read_search access. is that implied?
> 
> /etc/shadow is mode 640 on Debian.
> 
> On other distributions the choice is either more permissions for memlockd or a
> configuration that doesn't cache /etc/shadow.

Seems that we need an ifndef(`distro_debian' block with dac_read_search;

-- 
Chris PeBenito