Encrypted passwords in relay context

[thyssentishman]

as described in table(5), passwords have to be stored unencrypted when used in a relay context as they must be provided to the remote host.

Would it be possible to allow to launch an external program to decrypt the password when authenticating? For example msmtp (an SMTP client) has 'passwordeval' for this exact purpose. This would allow for integration with password managers for example.

Thank you.

[omar-polo]

I'm not sure exec'ing some random program in a random moment fits the privsep design of smtpd well.

Tables with secrets are meant to be owned by root and non readable by anyone except root, so that makes it decently secure IMHO.

However, this reminded me of @epsilon-0' table-procexec proposal which could fit well in here: https://marc.info/?l=openbsd-tech&m=167594803006464&w=2

[thyssentishman]

Tables with secrets are meant to be owned by root and non readable by anyone except root, so that makes it decently secure IMHO.

I agree.

However, this reminded me of @epsilon-0' table-procexec proposal which could fit well in here: https://marc.info/?l=openbsd-tech&m=167594803006464&w=2

Oh I didn't know about this. Read a little about it here but I'm not sure I get how it works. Also is it still available? I don't see it in opensmtpd-extras/extras/tables.

I asked on IRC as well and satanist suggested to maybe have the table file encrypted and to decrypt it from smtpd's init script (e.g. into a tmpfs filesystem for example). I think this is a good solution, however after some extra thought, this setup would require to provide a password (if the private key is password protected which is my case) when decrypting the file and I'm not sure how I would do this if the decryption is called from the init script.

[omar-polo]

I don't think table-procexec was ever committed, it was just a POC. It's a bit of a shame since it's a very nice idea.

but I'm not sure I get how it works.

OpenSMTPD uses "tables" to do lots of stuff. Users data is a table, the domain to serve could be a table, virtual and aliases are a table. The tables are a central data-type, for the configuration at least.

The idea of the table-procexec is to allow an external program to behave like a table much like the filters programs can act like "hooks".

You'd have to write a, let's say, table-password-store which speaks a simple line-protocol over standard input/output (simple enough that you can implement it in AWK) and use it to do what you want, e.g. quering password-store to extract relay passwords.

I asked on IRC as well and satanist suggested to maybe have the table file encrypted and to decrypt it from smtpd's init script (e.g. into a tmpfs filesystem for example).

IMHO this seems a needless complication. If your goal is to somehow never have the un-encrypted password on the file system, this yields nothing. On the other hand, if you can't trust root enough to keeping passwords in a root-owned file, I don't think you can trust your password-manager either.

Don't get me wrong, I see how something like this would be handy, but I think the cleaner way would be to use table-procexec.

[thyssentishman]

Thanks @omar-polo for the explanation and your opinion on the suggested alternative. What you say makes sense so I think i'll just stick with the root owned secrets file.

Regarding this issue, should I close it or is it something that might be worth implementing in the future?

[omar-polo]

I'd keep this open since it'd be a very welcome addition.

Thanks :)