Acabei de configurar um array RAID 1 usando mdadmo Debian. Estou tentando habilitar mdadmo monitoramento de e-mail usando msmtp. Estou seguindo a msmtpdocumentação ( https://marlam.de/msmtp/msmtp.html#Examples ) e quero armazenar minha senha do aplicativo Gmail usando secret-toolou gpg.
Ambas as ferramentas funcionam bem sozinhas:
- Posso recuperar a senha do meu aplicativo usando:
secret-tool lookup host smtp.gmail.com service smtp user [username]
ou
gpg --no-tty --quiet --decrypt ~/.msmtp-gmail.gpg
- Também posso enviar e-mails com sucesso usando:
echo "test email" | msmtp [emailaddess]@gmail.com
Entretanto, quando executo sudo mdadm --monitor --scan --test -1, obtenho a seguinte saída:
- Usando
secret-tool
sendmail: cannot read output of 'secret-tool lookup host smtp.gmail.com service smtp user [username]'
- Usando
gpg
gpg: can't open '/root/.msmtp-gmail.gpg': No such file or directory
gpg: decrypt_message failed: No such file or directory
sendmail: cannot read output of 'gpg --no-tty --quiet --decrypt ~/.msmtp-gmail.gpg'
- Usando senha armazenada em texto simples
sudo mdadm --monitor --scan --test -1 funciona quando eu armazeno a senha diretamente no /etc/msmtprcarquivo. No entanto, quero evitar isso.
Pergunta
secret-tool, gpg, e msmtptodos parecem estar funcionando corretamente quando executados pelo usuário. O problema parece ocorrer porque mdadmé executado com sudo.
Como posso contornar esse problema? Gostaria de aderir às melhores práticas para permissões/segurança de arquivos.
No final das contas, qualquer coisa que tenha acesso sem senha a alguns dados, tem acesso a esses dados.
A criptografia fornecida pelo secret-tool só é útil porque os dados não ficam disponíveis até que você faça login (e use sua senha de login para descriptografá-los¹) – mas se eles fossem desbloqueados o tempo todo, para torná-los disponíveis para o root, eles seriam... desbloqueados o tempo todo.
¹ é também por isso que a ferramenta não funciona quando executada por um usuário diferente; o serviço que contém os dados descriptografados é por usuário e o mdadm/secret-tool executado como root simplesmente não sabe que precisa se conectar ao armazenamento secreto do UID 1001.
O mesmo acontece com o GPG; você pode fazê-lo funcionar como root, mas a chave privada em si necessariamente terá que ser armazenada sem uma senha para que o mdadm possa usá-la, e se o arquivo criptografado estiver na mesma máquina que uma chave privada sem senha, então ele só será tão bom quanto estar em texto simples.
Existem algumas maneiras de fazer isso funcionar, por exemplo, executar gpg-agent como root para que você ainda possa ter uma chave protegida por senha que você desbloqueia uma vez por inicialização toda vez que o sistema reinicia – mas enquanto elas funcionam bem para certos casos de uso, um sistema de monitoramento RAID pode não ser um deles. (O que acontece se o servidor reinicia e você nunca consegue desbloquear o GPG para ele?)
Então, em um sistema headless, é relativamente normal manter credenciais em arquivos de texto simples que são acessíveis apenas ao root (ou alguma outra conta de serviço). Por exemplo, certificados de cliente ou servidor TLS são tipicamente simples, assim como keytabs Kerberos e chaves privadas de host SSH que identificam a máquina.
Embora o que mitigue parcialmente os riscos é que tais credenciais geralmente não são compartilhadas entre muitas coisas diferentes, mas pertencem exclusivamente àquele serviço, então elas podem ter acesso mais limitado. Ou seja, você não deve colocar os detalhes da sua própria conta do Gmail em /etc, mas em vez disso criar uma conta de e-mail dedicada (qualquer provedor) e usá-la como o "remetente". Dessa forma, você reduz os efeitos do vazamento dessas credenciais de "toda a sua identidade online está em risco" para "uma caixa de correio descartável sem nada dentro está em risco".