Como essa é uma pergunta muito boa, e foi interessante para mim, fiz algumas pesquisas que acabaram não sendo muito úteis.
Por fim, entrei em contato com #selinux no IRC Freenode e perguntei como a função padrão do selinux está selecionada. Felizmente, o usuário grift poderia fornecer as informações que faltavam para responder à sua pergunta.
O componente principal para definir o contexto do selinux é pam_selinux.so , que é responsável pela configuração da sessão. O módulo pam tem várias opções de configuração e também pode solicitar ao usuário, de forma interativa, o contexto desejado.
Caso não haja informações durante o login, ele volta a usar as informações armazenadas em /etc/selinux/$TYPE/contexts/user/$USERID , se não definido, usa o contexto __default__ definido em contexts/default_contexts .
root@u1604-cnt-host:/etc/pam.d# grep selinux *
lightdm:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
lightdm:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
lightdm-autologin:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
lightdm-autologin:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
lightdm-greeter:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
lightdm-greeter:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
login:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
login:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
sshd:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
sshd:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
systemd-user:session required pam_selinux.so close
systemd-user:session required pam_selinux.so nottys open
root@u1604-cnt-host:/etc/pam.d#
Como lightdm usa as mesmas pam_selinux.so chamadas como login ou sshd , isso não deve ser a origem do problema.
Em breve, tentei fazer a alteração desejada funcionar no Ubuntu, mas tive a impressão de que a política do selinux estava confusa no nível do processo. Então eu fiz alguns testes no Fedora:
[root@workbench users]# cat /etc/selinux/targeted/contexts/users/staff_u
system_r:local_login_t:s0 guest_r:guest_t:s0 staff_r:staff_t:s0
system_r:remote_login_t:s0 staff_r:staff_t:s0
system_r:sshd_t:s0 guest_r:guest_t:s0 staff_r:staff_t:s0
%<--- snipp ---%<
mudar system_r:sshd_t:s0 para guest_r:guest_t:s0 funciona bem, o usuário do selinux deve ter a função atribuída para funcionar. O processo sshd está sendo executado no domínio system_r:sshd_t .
Ao tentar alternar o contexto padrão de staff_u para sysadm_r:sysadm_t|system_r:system_r , o login volta para staff_r:staff_t:s0 ao substituir apenas a parte guest_r:guest_t . Isso está relacionado à política de system_r:sshd_t que não permite a mudança de contexto para system_r ou sysadm_t .
Definir uma combinação não funcional leva a unconfined_r:unconfined_t , que é o tipo padrão no Fedora targeted , pois default_contexts contém user_r:user_t para system_r:sshd_t , mas o usuário selinux não teve acesso à função user_r durante o teste.
Mais alguns detalhes sobre o assunto: