Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Dominick Grift <dominick.grift@defensec.nl>
To:     selinux-refpolicy@vger.kernel.org
Subject: Re: [PATCH] new sddm pam patch
Reply-To: <da3ba04d-9e76-677a-b1b2-2b65f9dc3892@ieee.org>
Date:   Mon, 25 Apr 2022 18:57:42 +0200
Message-ID: <875ymx5ce1.fsf@defensec.nl>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk


These desktop managers have a pam stack and that includes
/etc/pam.d/systemd-user which provides the user with a systemd --user
instance

If you do not add a seuser for these DM-users then their systemd --user
instance ends up with system_u:system_r:init_t:s0 (the context of pid1
which creates these systemd --user instances)

One possible solution would be if we could add clauses to pam config
files like for example:

if ! (user sddm) {
session ... pam_selinux.so ...
}

But not sure if something like that is even possible, and even if it was
possible, some parts of the DE need selinux in the pam stack (for
logging in the user)

But yes the main issue is the pam_selinux call in the pam_systemd
stack. Ideally we maintain some kind of compatibility with systems that
have pam_systemd and ones that do not

The alternative way is indeed to create a seuser so that we can tell
pam_selinux explicitly to stay is system_r:xdm_t:s0 (so the systemd
--user instance for the DE user will run in xdm_t and so all the
transitions will be the same whether the DE starts it via systemd --user
or manually starts it.

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift