Re: sddm issue and patch not for inclusion

[Dominick Grift <dominick.grift@defensec.nl>]

Russell Coker <russell@coker.com.au> writes:

> On Thursday, 28 January 2021 10:36:19 PM AEDT Dominick Grift wrote:
>> >> In Debian/Unstable (which will soon be frozen and become the next stable
>> >> release) the sddm X login program (the one that's generally recommended
>> >> and specifically known to generally work well with SE Linux) uses PAM to
>> >> start a session for the "greeter" (the program that asks for a password
>> >> before a new session is started).
>> >> 
>> >> With the policy currently in Debian that means the sddm user matches
>> >> "__default__" and gets unconfined_u:unconfined_r:unconfined_t, not what
>> >> is desirable for a program that takes input from unauthenticated users.
>> >> 
>> >> role xdm_r;
>> >> role xdm_r types xdm_t;
>> >> allow system_r xdm_r;
>> >> allow xdm_t xdm_tmpfs_t:file execmod;
>> > 
>> > that looks like a bug or at least bad code
>
> That's a design decision.  One could make a convincing argument that it's a 
> good decision.

Not sure whether doing text-relocation on a file you created yourself is
a good decision. From a security perspective does not seem like very
good thing to along, The more because xdm is shared between various
desktop managers.

>
>> >> corecmd_bin_entry_type(xdm_t)
>> 
>> Also wondering what or which bin_t file or files this applies to and if
>> it instead is not possible to give these a private type
>
> /usr/bin/sddm-greeter.  Yes I can give it a private type, might be a good idea 
> in any case.

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift