FreeIPA: impede que a raiz local acesse contas de usuários

Question

Então, depois de fazer essa pergunta, eu testei o FreeIPA como uma fonte de autenticação central com base nessa pergunta: Gerenciando o acesso a múltiplos sistemas linux

Um problema com o qual me deparo é que, se um usuário receber permissões de raiz local, ele poderá fazer login como qualquer usuário no diretório FreeIPA. Mesmo que os usuários não tenham acesso a essa máquina específica por meio das regras do HBAC.

Cenário de amostra:

• Máquina cliente FreeIPA PC1 .
• Dois usuários no FreeIPA: Bob e Alice.
• Alice não tem permissão para acessar o PC1 por meio das regras do HBAC. Bob tem raiz local no PC1. Bob pode su se tornar Alice no PC1.

A única informação que posso encontrar refere-se a comentar esta linha em /etc/pam.d/su:

auth            sufficient      pam_rootok.so

Que agora pede raiz local para a senha de Alice se ele tentar: su alice

No entanto, se Bob tiver acesso root, ele pode facilmente ativar a linha PAM / su acima. O FreeIPA não deve impedir que a conta de Alice acesse o PC1, seja por tentativa de login direto ou raiz local su -ing? Como se impede que raízes locais consigam se logar como qualquer usuário FreeIPA?

    

Answer 1

Eu classificaria isso como uma 'exploração de segurança' entre o relacionamento do (s) sistema (s) 'cliente' Linux e FreeIPA. Embora não seja necessariamente um 'bug', expande a capacidade das contas de raiz local para além da instância local de O / S (que não deveria ').

As declarações repetitivas de que esse problema é todo sobre o UNIX e como ele funciona estão incorretas. Embora uma conta 'raiz' tenha a capacidade de criar uma versão localizada de qualquer ID de conta e 'su' para ela, o uso do FreeIPA permite que a conta raiz local obtenha e acesse recursos existentes externamente à instância local (embora especificamente configurados ' não "estar disponível para isso".

Esse é um problema com a implementação do FreeIPA, permitindo que a conta "raiz" local escape de seus limites ...

    

Answer 2

Por favor, cheque a resposta do Simo Sorce em um Bugzilla relacionado, que resume bem o modelo de segurança do Linux e o que você pode ou não fazer como raiz local:

Hi Swartz, the root account on any linux machine is all powerful and can do anything it wants, it can even create local users and impersonate them w/o issue.

I suggest you take the time to understand what is the security model on Linux and what the root account can do (anything, including modifying the running kernel).

In any case a compromised machine cannot really do anything more, in a IPA environment, than what it can do in any other environment.

Unless the compromised machine steals actually active credentials it cannot influence other machines unless you are using insecure services that implictly trust any client.

In the NFS case for example root-squash is really not something you can trust any security upon, if you are concerned about access to NFS services you need to run NFS with sec=krb5, where each user access is authenticated via kerberos credentials.

If you are interested in a way to confine what users (including root) can do I suggest you read up on SELinux and capabilities and how to confine users of all kinds.

I am going to close this as NOTABUG, because there is nothing unaccounted for in what you are describing in the report, this is all known stuff.

    

Answer 3

Ok, se seu usuário é "root" local nessa máquina, ele pode fazer qualquer coisa nessa máquina. Bloquear "su -" não previne nada. "su -" supera tudo, é inerentemente local.

Para algo que você deseja realizar, é necessário projetar suas regras do HBAC em relação ao serviço chamado 'su-'. O principal aqui é que nenhuma conta de usuário deve ter raiz local nas caixas.

Espero que isso ajude.

    

Answer 4

Você teria que colocar isso em /etc/pam.d/su e /etc/pam.d/runuser :

auth       required    pam_localuser.so