Dominick Grift <dominick.gr...@defensec.nl> writes:

> Dominick Grift <dominick.gr...@defensec.nl> writes:
>
>> Michal Koutný <mkou...@suse.com> writes:
>>
>>> On Tue, Jul 22, 2025 at 06:21:28PM +0200, Dominick Grift 
>>> <dominick.gr...@defensec.nl> wrote:
>>>> To be clear:
>>>> 
>>>> 1. currently sd-pam does not always run as root
>>>
>>> Ah, good.
>>>
>>>> 2. when sd-pam does not run as root then it lacks permission needed to
>>>> do its job for some pam modules
>>>
>>> Such modules are frowned upon
>>> https://github.com/systemd/systemd/issues/8598#issuecomment-1883471227
>>
>> That is the answer I was looking for. It think it is unreasonable for
>> systemd to unilateraly decide to break these modules. This could
>> introduce security issues. Not to mention that systemd seemingly decides
>> its exceptional compared to other login programs.
>>
>
> The PAM module I am refering to is pam_selinux. It resets the terminal
> context when the session closes. However since the terminal is then
> owned by root and sd-pam runs as an unprivileged user it cannot reset
> it. Leaving it in a bad state.
>
> pam_close_session.3 states:
>
>        It should be noted that the effective uid, geteuid(2). of the
>        application should be of sufficient privilege to perform such
>        tasks as unmounting the user's home directory for example.
>

I believe that the issue was triggered by a bug so my apologies for
jumping the gun.

systemctl --user --machine=user@.host ... should not be using
/etc/pam.d/login (PAMName=login) I believe because it uses
systemd-stdio-bridge and it cannot/shouldnt be used with a pty. It think that a
custom /etc/pam.d/systemd-stdio-bridge (PAMName=systemd-stdio-bridge)
might be in order here so that we can call pam_selinux with
nottys. Other PAM modules might also suffer from this. I noticed that
pam_wtmpdb was unhappy too for some reason.

>>>
>>> Michal
>>>

-- 
gpg --locate-keys dominick.gr...@defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcini...@defensec.nl

Reply via email to