senhas diferentes, dependendo dos dispositivos conectados

Question

Eu gostaria de ter senhas diferentes para minha (s) conta (s): Quando (por exemplo) um determinado dispositivo USB é conectado, uma senha simples deve ser usada. A ideia é: se eu deixar meu computador, levo o bastão comigo e as senhas fáceis serão desativadas.

Minha ideia geral é:

1. Detecte o stick com o udev, talvez detecte determinados dados nele (com um script executado pelo udev) e reaja de acordo (por exemplo, crie um arquivo que é excluído quando o stick é conectado). Isso deve ser fácil.
2. Peça ao PAM que verifique a existência desse arquivo e selecione o banco de dados de senha de acordo.

A pergunta principal é provavelmente (ou seja, se eu entendi a estrutura do problema corretamente): O pam_unix2 pode ser configurado para usar outro arquivo de sombra? Acabei de dar uma olhada na página do manual para pam_unix2 e parece que isso não é possível porque este módulo permite que o NSS tome essa decisão.

    

Answer 1

Tanto o pam_unix quanto o pam_unix2 usam o libc para procurar o hash da senha, e o Glibc tem os locais /etc/nsswitch.conf e /etc/shadow codificados. Nem seria tão simples quanto recompilar pam_unix ou pam_unix2 : ambos passam pelo mecanismo NSS normal para verificar as senhas, eles usam somente seus conhecimentos de /etc/passwd , /etc/shadow e NIS para alterações de senha.

No entanto, você pode usar o % módulopam_pwdfile . Eu nunca usei, mas a descrição parece exatamente o que você está procurando.

This PAM module lets you use an arbitrarily-named text file similar in structure to /etc/passwd to authenticate users.

Alternativamente, você pode usar o pam_userdb , que verifica um senha em um banco de dados no formato Berkeley DB com um nome de arquivo passado como um argumento.

Agora, para detectar a presença do pendrive, você precisa de outro módulo PAM. pam_listfile parece certo para o trabalho. Organize uma regra do udev que monte sua chave USB e apenas essa chave USB, em um determinado local, diga /media/authentication-key ; crie um arquivo users.txt contendo a lista de nomes de usuários que podem usar uma senha mais curta. Se você quiser um teste mais complexo na pilha do PAM, você pode usar 'pam_exec .

Aqui está uma pilha que assume que /etc/shadow contém suas senhas strongs e /etc/passwd.weak contém suas senhas fracas. Aviso: não foi testado e não sou fluente no PAM, portanto, revise-o com atenção.

auth [success=ignore default=1] pam_listfile.so file=/media/authentication-key/users.txt iter=user sense=allow onerr=fail
auth [success=1 default=bad] pam_unix.so
auth [success=ok default=bad] pam_pwdfile.so pwdfile=/etc/passwd.weak
auth requisite pam_deny.so

    

Answer 2

Acabei de pensar que a parte difícil que tinha em mente poderia ser substituída por uma operação muito simples:

Provavelmente não é necessário configurar o PAM para usar um ou outro arquivo de senhas: deve ser possível apenas substituir /etc/shadow por um symlink e ter o script que ele acionou pelo udev para adicionar e remover eventos para substituir este link simbólico para que o procedimento normal do PAM (implicitamente) use uma ou outra versão do arquivo.

Desta forma, algumas contas podem ser impedidas de logins completamente sem o token de hardware.

    

Answer 3

Suponhamos que você escreve um arquivo de senha shadow-easy com o UUID do dispositivo que autoriza as substituições por senha, o nome de usuário, a Não fácil senha e fácil senha criptografada.

Isso apenas para os usuários que exigem senha fácil.

É possível pensar em uma substituição da string criptografada apenas para essa linha específica no etc/shadow . Somente quando um dispositivo autorizado (com alguns dados ....) está conectado.

Quando você adicionar / remover usuários ou modificar a senha, as duas sequências criptografadas não corresponderão e a substituição não ocorrerá. Então você precisa logar com a senha completa, e depois agir de outra forma.

Eu não quero pensar no que pode acontecer quando há falta de energia quando você toca no arquivo de sombra ou se o script falha ...

Continua a ser o problema que funcionará para todos os tipos de login, mesmo remoto. E mesmo que alguém envie comandos via ssh. Mas pode funcionar:)