Defina a senha do sudo de forma diferente do login um

Question

Como usuário privilegiado, estou tentando definir a senha sudo para outra que é usada no login.

Eu fiz algumas pesquisas, mas não encontrei uma resposta. O sudo suporta esse tipo de configuração?

Se você perder sua senha, você perderá tudo. Alguém poderia fazer login e se promover para root com a mesma senha.

sudo tem a opção de pedir root password em vez de senha de usuário invocada, ( rootpw ), mas compartilhar root password definitivamente não é uma opção, por isso configuramos sudo .

Eu fiz config 2FA no passado, funcionou muito bem, mas também venceu o propósito de automação. Por exemplo, se você deseja executar um comando privilegiado em uma dezena de servidores com um script expect , adicionar 2FA não permite que você faça isso.

A solução mais próxima que encontrei é permitir apenas a chave privada SSH e a frase-senha de configuração com uma chave que difere da senha sudo (login). Ainda assim, não é confortável, porque em uma situação de emergência você não pode entrar com um PC onde não tem essa chave.

    

Answer 1

Se você quiser solicitar a senha de root, ao contrário da senha do usuário, há opções que você pode colocar em /etc/sudoers . rootpw em particular fará com que ele peça a senha de root. Há runaspw e targetpw também; veja o sudoers (5) manpage para detalhes.

Além disso, o sudo faz sua autenticação (como todo o resto) através do PAM. O PAM suporta a configuração por aplicativo. A configuração do Sudo está em (pelo menos no meu sistema Debian) /etc/pam.d/sudo , e é assim:

$ cat sudo 
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

Em outras palavras, por padrão, ele autentica como tudo o mais no sistema. Você pode alterar essa linha @include common-auth e fazer com que o PAM (e, portanto, o sudo) use uma fonte de senha alternativa. As linhas não comentadas na autenticação comum são semelhantes a (por padrão, isso será diferente se você estiver usando, por exemplo, LDAP):

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Você poderia usar, por exemplo, pam_userdb.so em vez de pam_unix.so e armazenar suas senhas alternativas em um banco de dados do Berkeley DB.

exemplo

Eu criei o diretório /var/local/sudopass , proprietário / grupo root:shadow , modo 2750 . Dentro dele, eu fui em frente e criei um arquivo de banco de dados de senhas usando db5.1_load (que é a versão do Berkeley DB em uso no Debian Wheezy):

# umask 0027
# db5.1_load -h /var/local/sudopass -t hash -T passwd.db
anthony
WMaEFvCFEFplI
^D

Esse hash foi gerado com mkpasswd -m des , usando a senha "password". Muito altamente seguro! (Infelizmente, o pam_userdb parece não suportar nada melhor do que o antigo hashing crypt(3) ).

Agora, edite /etc/pam.d/sudo e remova a linha @include common-auth e, em vez disso, coloque isso em prática:

auth    [success=1 default=ignore]      pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Observe que o pam_userdb adiciona uma extensão .db ao banco de dados passado, portanto você deve deixar o .db off.

De acordo com dannysauer em um comentário , você pode precisar fazer a mesma edição para /etc/pam.d/sudo-i também.

Agora, para sudo, devo usar password em vez da minha senha de login real:

anthony@sudotest:~$ sudo -K
anthony@sudotest:~$ sudo echo -e '\nit worked'
[sudo] password for anthony: passwordRETURN

it worked

    

Answer 2

Para Redhat / Centos, a exigência pode ser obtida com as seguintes etapas:

Crie um usuário personalizado e passe:

# db_load -t hash -T /usr/local/etc/passwd.db
user
pass
^d

Edite o arquivo sudo pam.d para que pareça:

$ cat /etc/pam.d/sudo

auth            required        pam_userdb.so db=/usr/local/etc/passwd
account         required        pam_userdb.so db=/usr/local/etc/passwd
password        include         system-auth

session         optional        pam_keyinit.so revoke
session         required        pam_limits.so

Ainda estou procurando o caminho para a configuração, de modo que apenas um determinado usuário / grupo deva ser autenticado por este método personalizado, outros ainda podem ser authen pelo método normal system-auth. Alguém pode me dar alguns conselhos?

    

Answer 3

Eu não acho que o sudo suporte essa configuração. O objetivo da solicitação de senha sudo é garantir que a pessoa que está emitindo o comando sudo seja a mesma pessoa que está conectada, e a maneira mais fácil de fazer isso é solicitar que o usuário atualmente conectado se autentique novamente.

Em outras palavras, a finalidade do prompt de senha do sudo é não para estabelecer autoridade , é estabelecer identidade . Com base na identidade estabelecida e na configuração do sudo, uma decisão pode ser tomada se o usuário em questão tiver a autoridade necessária ou os direitos de acesso.

    

Answer 4

Sua preocupação é que a senha da sua conta possa ser divulgada. A solução é não usar a senha de login de maneira que possa ser divulgada. Com ssh, a senha é criptografada no fio, então está tudo bem. As pessoas desativam a autenticação de senha com o ssh para evitar ataques de adivinhação de senha, e não para proteger a confidencialidade da senha. Se você estiver usando a mesma senha de conta para qualquer outra coisa, verifique se está usando um canal criptografado seguro para fornecer a senha. Se você está preocupado com um keylogger ou qualquer outra coisa, pare de usar máquinas não confiáveis para efetuar login.

Se alguém puder obter sua senha ssh, provavelmente também obterá a senha sudo alternativa, então é melhor investir tempo para tornar suas conexões mais seguras do que gastar tempo apenas tornando as coisas mais complicadas apenas para a ilusão de mais segurança .

    

Answer 5

Eu não tenho acesso imediato a um sistema em que posso testar isso e descobrir os detalhes, mas tenho uma ideia:

• (suponha que sua conta de login normal seja shau .)
• Crie uma segunda conta: shau2 . (Não tenho certeza se você deseja que ele tenha o mesmo UID que shau .)
• Configure shau2 para ter privilégios sudo com NOPASSWD.
• Configure um alias ou um script de shell para fazer su shau2 -c sudo "$@" . Isso deve pedir a senha de shau2 . Se isso for digitado corretamente, ele será executado sudo as shau2 (que não deve pedir uma senha).
• Remova os privilégios sudo de shau .

Infelizmente, você teria que repetir isso para todos os usuários com privilégios de sudo.

    

Answer 6

Obrigado @ Shu Shắc pela resposta ! Essa solução também funciona para LinuxMint 17.1 Cinnamon 32bit (eu instalei apenas o pacote db-util para executar db_load ).

Mas estou muito confuso com o arquivo passwd.db resultante. Eu fiz o mesmo que na sua resposta (mas usou david e jones , eles parecem mais atraentes):

# db_load -t hash -T /usr/local/etc/passwd.db
david
jones
^d

Mas as credenciais inseridas são armazenadas no arquivo hash como texto simples:

# grep 'jones.*david'  /usr/local/etc/passwd.db
Binary file /usr/local/etc/passwd.db matches

Você também pode ver david e jones via mcedit :

Sim, é possível restringir as permissões de /usr/local/etc/passwd.db . Mas, de qualquer forma, o nome de usuário e a senha armazenados como texto simples são ruins.

Mesmo com a senha separada sudo , existem algumas falhas potenciais de segurança (por padrão, a configuração da distribuição). Assim, a senha separada não é aplicável para su (portanto, é possível iniciar a sessão raiz usando su e senha de login). Também a senha separada não é respeitada pelo Policy Kit (é possível iniciar o Synaptic usando synaptic-pkexec e a senha de login. Em seguida, exclua os pacotes ...). Esses problemas podem ser eliminados pelo ajuste adicional dos arquivos de configuração.

Em geral, parece que a senha do sudo separada e segura pode ser obtida apenas com o auxílio do módulo PAM personalizado (talvez, esse módulo compara a senha e o hash SHA-512 do arquivo) ou a funcionalidade do SELinux.

PS: desculpe, deve ser um comentário. Mas vai como resposta por causa do formato de texto. Obrigado pela compreensão.