The OpenDKIM ebuild currently appropriates the "milter" user for use by OpenDKIM: enewuser milter -1 -1 /var/lib/milter milter However, the OpenDKIM user needs to be able to read your private DKIM signing keys. That's top-secret information that no one else should be able to read, not even postfix or amavisd-new; only the opendkim daemon needs them. If the "milter" user was exclusive to OpenDKIM, that would be fine -- but it's not. A quick grep turns up at least the following: * mail-filter/milter-regex * mail-filter/opendmarc * mail-filter/sid-milter * mail-filter/spamass-milter So instead, I would suggest we create and use the "opendkim" user from now on. That will be the user/group who accesses the secret keys, and should not be shared with anything else. If, for example, you need the "opendkim" user to share a socket with postfix, then the safest way to do that is to create a new, unrelated group, and add "opendkim" and "postfix" to it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bef349fb49583b1d4249af3f490d02db049066d5 commit bef349fb49583b1d4249af3f490d02db049066d5 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2019-03-27 14:36:32 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2019-03-27 17:18:05 +0000 mail-filter/opendkim: new revision with a dedicated "opendkim" user. Prior to this revision, the OpenDKIM daemon would run as the "milter" user, which is a username shared by a few other related packages. However, that user has the ability to read your private DKIM signing keys, and no other services should have access to those. Thus, sharing the user account creates a security risk. In the new revision, a dedicated "opendkim" user is created for the OpenDKIM daemon. The configuration, OpenRC service script, and systemd service files have all been updated with the new user name. In addition, the permissions on /var/lib/opendkim have been tightened so members of the "opendkim" group can only read it by default. The daemon does not need to modify your keys, in particular, and should not be able to. One downside to this is that the "Statistics" configuration directive that was enabled by default with USE=berkdb will no longer work out-of-the-box. It will still work, but the administrator will need to grant write access to the file that he designates for the statistics data. But since it won't work without some extra fiddling, it has been removed from the configuration file that we install. An ewarn notifies users who are upgrading of the account name change. Closes: https://bugs.gentoo.org/629888 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> Package-Manager: Portage-2.3.62, Repoman-2.3.11 mail-filter/opendkim/files/opendkim-r2.service | 15 ++++++ mail-filter/opendkim/files/opendkim.init.r4 | 55 ++++++++++++++++++++++ ...-2.10.3-r5.ebuild => opendkim-2.10.3-r6.ebuild} | 37 +++++++++------ 3 files changed, 92 insertions(+), 15 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d424c81f020cada007c5ca23be5acc73f4cf6600 commit d424c81f020cada007c5ca23be5acc73f4cf6600 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2019-04-06 11:31:17 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2019-04-06 11:31:38 +0000 mail-filter/opendkim: remove old vulnerable revision. Bug: https://bugs.gentoo.org/629914 Bug: https://bugs.gentoo.org/629888 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> Package-Manager: Portage-2.3.62, Repoman-2.3.11 mail-filter/opendkim/opendkim-2.10.3-r3.ebuild | 204 ------------------------- 1 file changed, 204 deletions(-)
