TL; DR : Sim, eles podem ter um efeito, mas no seu sistema, eles provavelmente não o fazem.
Primeiro, alguns antecedentes:
A maioria das distribuições Linux que enviam o SELinux estão usando uma política baseada na chamada política de referência , que contém uma política funcional que pode ser usado como base para personalização específica do site ou usado como está.
Os atributos que você está vendo são: o usuário do SELinux, a função e o tipo (ou domínio) do arquivo ou processo. No SELinux, os usuários de login são mapeados para usuários do SELinux e, em seguida, os usuários do SELinux são atribuídos a funções que eles podem executar. Cada função tem um conjunto de domínios para os quais ela pode fazer a transição. Dessa forma, pode-se mudar a função de um usuário (os usuários podem alternar sua própria função com o comando newrole , se tiverem permissão para alterar funções) para fornecer ou negar acesso a um conjunto completamente diferente de domínios.
No caso de arquivos, o acesso ao arquivo é mediado com base no usuário e na função do processo que corresponde ao usuário e à função com a qual o arquivo está rotulado. No entanto, no caso de usuários não confinados, (e sempre que você quiser, em suas próprias políticas personalizadas), eles podem ser ignorados e apenas o tipo usado ou o tipo também ignorado.
Se você estiver usando a política segmentada padrão, o usuário e a função são quase totalmente não utilizados, pois essa política realmente faz muito pouco com o controle de acesso baseado em usuário ou função, concentrando-se em confinar enfrentando serviços em vez disso. Essa política tem algum suporte para confinar usuários, mas está desativada por padrão e todos os logins de usuários interativos não são delimitados.
Sob as políticas strict ou mls , o controle de acesso baseado em usuário e função é muito mais usado . Os usuários sempre ficam confinados nessas políticas e até mesmo o que o usuário root pode fazer é limitado colocando o usuário root na função sysadm_r . Note que a política mls faz com que o X seja quebrado, então você geralmente não o verá nas estações de trabalho.
A maioria dos sistemas SELinux com os quais você provavelmente se deparará estará usando apenas a política segmentada ; é incomum encontrar strict ou mls em uso, embora você o veja em locais que exijam a segurança baseada em usuário e função (por exemplo, contratados de defesa). Nesses casos, você provavelmente verá que eles personalizaram os usuários e as funções em uso.
É possível escrever uma política SELinux completa a partir do zero, mas como esse é um lote de trabalho, e carrega seu próprio conjunto de pesadelos (por exemplo, documentação ou falta deles) você não verá Muito frequentemente. Embora se você quiser ver uma demonstração do controle de acesso baseado em função, este exemplo da IBM de um política escrita do zero funciona bem.
(Uma resposta completa seria ainda mais teoria, então eu vou deixar você com isso. Dia-a-dia, o O SELinux User Guide é seu amigo, e para as perguntas realmente difíceis do SELinux, o lista de discussão também é sua amiga.)