Red Hat- and Debian- derived distributions support SELinux, and so their
sudo packages are built with SELinux support. However, other
distributions (notably Arch) build sudo without SELinux. Such sudo
builds will fail to parse the `ROLE=unconfined_r TYPE=unconfined_t`
string added in 0fac1aa45c. They *can*
parse `role=unconfined_r, type=unconfined_t` in `Defaults`, but that
causes problems on some Fedora 33 systems if SELinux is turned off and
the root account is locked.
To solve both of these problems at once, we install a different
`/etc/sudoers.d/qubes` file depending on the distribution. As a
heuristic, we use the presents of `/etc/redhat-release` or
`/etc/debian_version`. If either is present, sudo probably supports
SELinux, and we should include the corresponding entries. If both are
missing, then we shouldn’t risk it. The `qubes.sudoers` file in the git
repository includes the full file (with SELinux); we use `sed` to strip
the SELinux portion when needed.
By settinf Defaults role/type parameters, sudo starts asking for
password when called as root. It isn't clear why this happens, but
rollback that change. Instead, set ROLE/TYPE just for the rule for the
'qubes' group, which already has NOPASSWD option.
Fixes 3bcc1c3 "“sudo” must remove SELinux restrictions"
Otherwise, if “user” has the SELinux user “staff_u”, the user will
typically need to write “sudo -r unconfined_r -t unconfined_t”, which is
annoying. If SELinux is disabled, these fields are ignored.
Without this restriction system users can start processes with
root privileges:
$ sudo -u mail systemd-run --pipe -q id
uid=0(root) gid=0(root) groups=0(root)
In Red Hat based distributions, there is no pam-configs like
mechanism (authselect seems too heavy and is not configured by
default), so instead, we replace the PAM file.
Enable su for users in the qubes group, same as in the Debian
package.
