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)
