Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] another systemd misc patch
To:     Chris PeBenito <pebenito@ieee.org>
Cc:     Russell Coker <russell@coker.com.au>,
        selinux-refpolicy@vger.kernel.org
References: <YBoZF4R5Pf4meO19@xev>
 <8e419ea2-1ba4-5b44-16ae-8fbe80cacf18@ieee.org>
 <ypjl5z36qnem.fsf@defensec.nl>
 <0c8ef4b6-893a-134c-d8ba-c0a6af4e8638@ieee.org>
From:   Dominick Grift <dominick.grift@defensec.nl>
Message-ID: <df3be15f-7d9a-3863-521d-cab42cc9e143@defensec.nl>
Date:   Fri, 5 Feb 2021 21:45:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <0c8ef4b6-893a-134c-d8ba-c0a6af4e8638@ieee.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 2/5/21 9:31 PM, Chris PeBenito wrote:
> On 2/5/21 3:18 PM, Dominick Grift wrote:
>> Chris PeBenito <pebenito@ieee.org> writes:
>>> On 2/2/21 10:31 PM, Russell Coker wrote:
>>>> Lots of littls changes related to systemd.
>>>> Signed-off-by: Russell Coker <russell@coker.com.au>
> 
>>>> @@ -925,14 +1001,26 @@ allow systemd_nspawn_t systemd_nspawn_tm
>>>>    # for /run/systemd/nspawn/incoming in chroot
>>>>    allow systemd_nspawn_t systemd_nspawn_runtime_t:dir mounton;
>>>>    +kernel_getattr_core_if(systemd_nspawn_t)
>>>> +kernel_getattr_proc(systemd_nspawn_t)
>>>> +kernel_getattr_unlabeled_dirs(systemd_nspawn_t)
>>>> +
>>>>    kernel_mount_proc(systemd_nspawn_t)
>>>>    kernel_mounton_sysctl_dirs(systemd_nspawn_t)
>>>>    kernel_mounton_kernel_sysctl_files(systemd_nspawn_t)
>>>>    kernel_mounton_message_if(systemd_nspawn_t)
>>>>    kernel_mounton_proc(systemd_nspawn_t)
>>>> +kernel_mounton_sysctl_files(systemd_nspawn_t)
>>>> +kernel_mounton_unlabeled_dirs(systemd_nspawn_t)
>>>
>>> With all of the mounting, perhaps we should consider coalescing on
>>> allowing it to mount an all init_mountpoint_types.
>>
>> mounton unlabeled dirs indicates that something is unlabeled/mislabeled
>> though. Wouldnt allow that.
> 
> Yes I agree.  I noticed all the mountons but didn't notice this specific
> one.
> 

I know how that goes, i probably "reviewed" this patch and overlooked
this wrole wtuff ...
>