/etc/ssmtp/ssmtp.conf leaks credentials because the file is readable by anyone able to send email. A flawed attempt to fix this was done in bug #187841. However anyone added to the ssmtp group is now able to read the credentials because the conf file is not protected. So the protection is nil, and there is a large (unwanted) side effect that users that could send email are suddenly not able to send email anymore after ssmtp upgrades. A potential way to fix the data leakage problem is to make the ssmtp binary suid root and change the permissions of the conf file to 0600. This scenario is what suid binaries exist for. One should not be afraid of using suid binaries due to some overzealous security mantra. Another potential fix is to add a USE flag that disables the ssmtp group creation and special permissions for setups that don't use credentials for sending email. This would allow one to restore ssmtp to the older behavior, which happens to be consistent with the other MTAs Gentoo supports.
What credentials?
(In reply to comment #1) > What credentials? > username/password to log in to a smtp relay. adding security@g.o for an advice.
New ssmtp default settings do really need to be changed. Of course security is important, but ssmtp is intended to be simple MTA. With the new behavior, ssmtp will not work at all after it is installed, while sendmail and any other MTA will just work without any additional configuration. I'me agree with David Sparks that new behavior should be made optional and disabled by default, or even the ebuild should be just reverted back to the previous simple behavior.
If you want people not to gain knowledge of the login credentials, the ssmtp group solution is not the way to go. It does limit the number of users that can access the file (to those who are selected to be able to send mail), but they can still read the password. This is not a problem in proper setups (because should only allow them to send mail, which they can do before already), but the password might be used in other contexts. What about keeping the file 0640 root:ssmtp, and make /usr/sbin/ssmtp root:ssmtp, but 02710 (setgid ssmtp)?
Thanks for your feedback Robert! (In reply to comment #4) > What about keeping the file 0640 root:ssmtp, and make /usr/sbin/ssmtp > root:ssmtp, but 02710 (setgid ssmtp)? > That's one solution I thought about - and for now I think that's the way it should be. I'd make this the default behaviour, but for people who don't see this potentional password leakage as a problem or leak in their specific setups I'll add a use-flag to disable the setgid protection and restore the "old" behaviour that way. Any objections on that?
setgid (2711) on the ssmtp binary as of 2.62-r4.
