treasy

SELinux is overly complicated, but it’s not hard to at least grasp the basics

The amount of people confusing DAC and MAC is concerning. You’ve done an excellent job explaining the topic.

Those files would be editable by something in the sysadm_t domain which is by default the domain of the root user after a successful authentication

This backdoor does not bypass remote authentication so it should be able to transition to the new domain that has access to these files

Selinux domains are uncoupled from Linux users. If sshd does not have Selinux permissions to edit those files it will simply be denied. Even if sshd is run as root

libselinux is the userspace tooling for selinux, it is irrelevant to this specific discussion as the backdoor does not target selinux in any way, and sshd does not have the capabilities required to make use of the libselinux tooling anyway

libselinux is just an unwitting vector to link liblzma with openssh

If you look at the diagram of privsep, the authentication process is part of the privileged binary, which is where this RCE lives

http://www.citi.umich.edu/u/provos/ssh/priv.jpg

You can definitely prevent a lot of file/executable accesses via SELinux by running sshd in the default sshd_t or even customizing your own sshd domain and preventing sshd from being able to run binaries in its own domain without a transition. What you cannot prevent though is certain things that sshd _requires_ to function like certain capabilities and networking access.

by default sshd has access to all files in /home/$user/.ssh/, but that could be prevented by giving private keys a new unique file context, etc.

SELinux would not prevent all attacks, but it can mitigate quite a few as part of a larger security posture