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;
To:     Russell Coker <russell@coker.com.au>
Cc:     selinux-refpolicy@vger.kernel.org
References: <YAgBKwxkaxUV4H99@xev> <1730727.gRP4Mpsj7r@liv>
 <60db511b-f9a3-5489-182b-88a0b727b9c2@defensec.nl> <3798733.Xe6EjoDzsm@liv>
From:   Dominick Grift <dominick.grift@defensec.nl>
Subject: Re: [PATCH] misc services patches
Message-ID: <5a0604c0-edc3-5fff-d02c-547c59382a2f@defensec.nl>
Date:   Fri, 22 Jan 2021 08:02:13 +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: <3798733.Xe6EjoDzsm@liv>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 1/22/21 3:24 AM, Russell Coker wrote:
> On Friday, 22 January 2021 12:35:42 AM AEDT Dominick Grift wrote:
>>>>> +++ refpolicy-2.20210120/policy/modules/services/ssh.te
>>>>> @@ -268,6 +268,7 @@ ifdef(`init_systemd',`
>>>>>
>>>>> init_dbus_chat(sshd_t)
>>>>> systemd_dbus_chat_logind(sshd_t)
>>>>> init_rw_stream_soconnectivitycheck.cbg-app.huawei.comckets(sshd_t)
>>>>>
>>>>> +       systemd_read_logind_sessions_files(sshd_t)
>>>>
>>>> This should probably be addressed on the lower authlogin level instead
>>>
>>> auth_login_pgm_domain()?
>>
>> I would consider adding it to auth_use_pam(). but its a good question.
>>
>>> In another patch I have systemd_connect_machined(sshd_t) which I guess
>>> should go in the same one too.
>>
>> Which patch was that?
> 
> A patch I haven't sent to the list yet.
> 
>> That does not look right if only that the name of
>> the interface isnt very descriptive (there is no way unix stream connect
>> or unix dgram sendto machined.
>>
>> So this is either about systemd's nss mymachines (in which case it
>> belongs in auth_use_nsswitch() or about reading systemd
>> /var/run/machines in which case the interface name is wrong.
> 
> I don't have the libnss-systemd or libnss-mymachines packages installed on the 
> machines that are giving this, /etc/nsswitch.conf hasn't been changed since 
> 2018.
> 
> When I comment out the pam_systemd.so line from /etc/pam.d/common-session that 
> access isn't required.  So it's a PAM thing.
> 
> +interface(`systemd_connect_machined',`
> +       gen_require(`
> +               type systemd_machined_t;
> +       ')
> +
> +       allow $1 systemd_machined_t:unix_stream_socket connectto;
> +')
> 
> Should I put this access in systemd_stream_connect_userdb()?  The socket file 
> is /run/systemd/userdb/io.systemd.Machine and is labelled as 
> systemd_userdb_runtime_t.
> 

I forgot about this functionality. From systemd-machined.service:

       For each container registered with systemd-machined.service that
       employs user namespacing, users/groups are synthesized for the
       used UIDs/GIDs. These are made available to the system using the
       User/Group Record Lookup API via Varlink[4], and thus may be
       resolved with userdbctl(1) or the usual glibc NSS calls.

So this is "nss password/group" similar to DynamicUser.io I guess

What i did in my personal policy is create a
machined_unix_stream_connect_userdb (roughly):

https://git.defensec.nl/?p=dssp3.git;a=blob;f=policy/systemd/systemd_machine.cil;h=9ea214e7d124e2be4254e57c7bf78e09914db7bf;hb=HEAD#l72

and then call that in auth_use_nsswitch() optionally (because if you
dont have machined then you dont need this)