Re: [PATCH] misc services patches

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)