1

I just set up a RAID 1 array using mdadm on Debian. I am trying to enable mdadm email monitoring using msmtp. I am following the msmtp documentation (https://marlam.de/msmtp/msmtp.html#Examples) and want to store my Gmail app password using either secret-tool or gpg.

Both tools work fine on their own:

  • I can retrieve my app password using:
secret-tool lookup host smtp.gmail.com service smtp user [username]

or

gpg --no-tty --quiet --decrypt ~/.msmtp-gmail.gpg
  • I can also successfully send emails using:
echo "test email" | msmtp [emailaddess]@gmail.com

However, when I run sudo mdadm --monitor --scan --test -1, I get the following output:

  • Using secret-tool
sendmail: cannot read output of 'secret-tool lookup host smtp.gmail.com service smtp user [username]'
  • Using 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'
  • Using password stored in cleartext

sudo mdadm --monitor --scan --test -1 does work when I store the password directly in the /etc/msmtprc file. However, I want to avoid this.

Question

secret-tool, gpg, and msmtp all seem to be working correctly when run by the user. The issue seems to occur because mdadm is run with sudo.

How can I get around this issue? I would like to adhere to best practices for file permissions/security.

Giacomo1968
  • 58,727
D'Marcus D'Muro
  • 13

1 Answers1

1

Ultimately, anything that has passwordless access to some data, has access to that data.

The encryption provided by secret-tool is only useful because the data is not available until you log in (and use your logon password to decrypt it¹) – but if were unlocked all the time, for making it available to root, it'd be...unlocked all the time.

¹ this is also why the tool doesn't work when run by a different user; the service holding the decrypted data is per-user and mdadm/secret-tool running as root just doesn't know it'd have to connect to UID 1001's secret storage.

The same with GPG; you can make it work as root, but the private key itself will necessarily have to be stored without a passphrase for mdadm to use it, and if the encrypted file is on the same machine as a passwordless private key, then it's only as good as being in plain text.

There are some ways to make this work, e.g. running gpg-agent as root so that you can still have a passphrase-protected key that you unlock once per boot every time the system reboots – but while those work well for certain use cases, a RAID monitoring system might not be one of them. (What happens if the server reboots and you just never get around to unlocking GPG for it?)

So on a headless system, it's relatively normal to keep credentials in plain text files that are only accessible to root (or some other service account). For example, TLS client or server certificates are typically in plain, as are Kerberos keytabs and SSH host private keys that identify the machine.

Though what partially mitigates the risks is that such credentials usually aren't shared between many different things but belong exclusively to that service, so they can have more limited access. That is, you should not put your own Gmail account details in /etc, but instead create a dedicated email account (any provider) and use it as the "sender". That way you reduce the effects of leaking those credentials from "your entire online identity is at risk" to "a throwaway mailbox with nothing inside is at risk".

grawity
  • 501,077