In init.d/opendkim we have: checkpath -q -d -o milter:milter -m 0755 "${PIDDIR}" || return 1 in our case we run opendkim under amavis:amavis, so this should be configurable through /etc/conf.d/opendkim Reproducible: Always
I'm going to start filing some bugs about the OpenDKIM init scripts... there are a few problems with this line: 1. OpenDKIM needs its own user/group; it shouldn't share "milter" with other packages. I'm going to suggest "opendkim". 2. It gives ownership of the PID file directory to an untrusted user, and that can be exploited to kill root processes. However, I don't think that the right way to fix it is to make the user configurable. If you ever change the user, the OpenDKIM daemon will fail to start (the permissions on your OpenDKIM config/keys will be all wrong). Instead, I think we should hard-code this to a dedicated user like "opendkim". Why are you running as amavis:amavis? Is it in order to share a socket with amavisd-new? If it is, there's a better way to accomplish the same thing. Assuming we've switched OpenDKIM to use the "opendkim" user, you would create a third, new, group and add both "opendkim" and "amavis" to that group. If you made the new group the *primary* group of the opendkim user, then the socket would be created as that group, and amavis could write to it. That doesn't require a switchable UserID, and it's much better for security: amavisd-new has no business being able to read your private keys!
Yes, I'm running it in that way to share common socket with amavis. I see your point and think that you are right, but making third group and changing primary is a bit overkill, so I propose to have a separate user for opendkim (configurable, because it is a 'gentoo' way. if user change it than he takes full responsibility for right permissions on config, it is better then change init.d scripts if it is needed) and primary group like milter or whatever that can be shared amongst all programs that need to access to milter sockets.
It's not too much work once you know the trick: $ groupadd dkimsocket $ usermod -a -G dkimsocket postfix $ usermod -g dkimsocket opendkim $ usermod -a -G opendkim opendkim Afterwards, the socket will be created as opendkim:dkimsocket. I made some suggestions in bug 629888 and bug 629914. Having a third group like that solves one other problem I ran into, but we could definitely use some better documentation on how to run with a local socket.
ok, np.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e35c9f5cb7862d43cecc76cf4159bae5b71ff9c commit 1e35c9f5cb7862d43cecc76cf4159bae5b71ff9c Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2019-03-27 16:01:33 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2019-03-27 17:18:08 +0000 mail-filter/opendkim: add an elog about sharing a local socket. Sharing a local OpenDKIM socket with an MTA is far too tricky. This commit adds an elog with some vague hints, but we really need a decent wiki page with some step-by-step instructions. This is progress towards bug 575666, but I won't consider that resolved until we have a wiki page. Bug: https://bugs.gentoo.org/575666 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-r7.ebuild | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Here is how I share a socket between OpenDKIM and Postfix: # /etc/conf.d/opendkim OPENDKIM_SOCKET="local:/run/opendkim/socket" # /etc/opendkim/opendkim.conf UMask 0117 UserID opendkim:postfix $ ls -l /run/opendkim srw-rw---- 1 opendkim postfix 0 Mar 29 19:59 socket= This way, no additional group is required.
(In reply to Ralph Seichter from comment #6) > > UMask 0117 > UserID opendkim:postfix > That's probably fine for most people, but I hesitate to officially recommend it because it lets everyone in the postfix group read your private DKIM signing keys. If someone doesn't use a dedicated key for DKIM, then they expose that key to an MTA that now has the power to mess up more than your mail. Or maybe you have some interns in the postfix group to allow them to edit alias maps -- they shouldn't be able to steal your signing keys. Maybe those examples are far-fetched, but whenever possible I rather tell people the safe thing and let them make their own exceptions for convenience. CYA and all that.
(In reply to Michael Orlitzky from comment #7) > That's probably fine for most people, but I hesitate to officially recommend > it because it lets everyone in the postfix group read your private DKIM > signing keys. How does having group write access to the shared socket let group members read private key material? I thought that no data transfer beyond the scope of the milter protocol was possible via this socket?
(In reply to Ralph Seichter from comment #8) > (In reply to Michael Orlitzky from comment #7) > > How does having group write access to the shared socket let group members > read private key material? It doesn't, I might have jumped the gun. What are the permissions on your key files and the directories that contain them? One other security goal I'd like to ensure is that only root can modify the keys, but of course OpenDKIM needs to read them. In the new ebuilds, that's accomplished by fowners root:opendkim /var/lib/opendkim fperms 750 /var/lib/opendkim in src_install, and then later (these files start out root:root mode 700), chgrp opendkim "${ROOT}var/lib/opendkim/${selector}".{private,txt} chmod g+r "${ROOT}var/lib/opendkim/${selector}".{private,txt} in pkg_config. So the important stuff is root:opendkim out of the box, and the only way you can read it is via group membership. If you run the opendkim daemon as group "postfix", I was assuming that group permissions were still being used to allow read access to the key files, meaning that the postfix group could read them. But maybe you have a better way? Even though I committed this stuff yesterday, it was all written over a year ago so I won't swear that it's 100% correct =)
(In reply to Michael Orlitzky from comment #9) > What are the permissions on your key files and the directories > that contain them? $ ls -al /etc/opendkim total 48K drwxr-xr-x 2 root root 4.0K Sep 23 2018 ./ drwxr-xr-x 7 root root 4.0K Mar 29 20:37 ../ -r-------- 1 opendkim opendkim 1.7K Feb 3 2018 mumble.key -r--r--r-- 1 root root 451 Feb 3 2018 mumble.pub Read access to the private key file can be limited to that single user, no group access is required. Write access is not necessary at all. So, I suggest the following: chown opendkim:opendkim mumble.key && chmod 0400 mumble.key
(In reply to Michael Orlitzky from comment #9) > If you run the opendkim daemon as group "postfix" [...] Sorry, I forgot to reply to that paragraph. I do not run OpenDKIM with a group shared by Postfix. I don't even know why anyone would do that. Apart from the shared socket file, Postfix and OpenDKIM are disjunct. Seen from Postfix's perspective, OpenDKIM is just another milter.
(In reply to Ralph Seichter from comment #10) > > Read access to the private key file can be limited to that single user, no > group access is required. Write access is not necessary at all. So, I > suggest the following: > > chown opendkim:opendkim mumble.key && chmod 0400 mumble.key Sadly the chmod doesn't really do anything there. The owner of a file can always chmod it again and then write to it. The write ability probably only matters if a key is being used for more than one purpose... I guess I could be convinced, I'll mull it over.
(In reply to Ralph Seichter from comment #11) > I do not run OpenDKIM with a group shared by Postfix. I don't even know why > anyone would do that. Wait, what does this do then? > UserID opendkim:postfix Do I need to go read the man page? :( I presumed that line drops privileges to user=opendkim and group=postfix after starting the daemon. (Which brings up another problem... can the opendkim daemon then read your group=postfix stuff under /etc/postfix?)
(In reply to Michael Orlitzky from comment #12) > Sadly the chmod doesn't really do anything there. The owner of a file can > always chmod it again and then write to it. The chmod is only meant to prevent OpenDKIM from inadvertently opening the key in write mode. Not that that ever happened, I would have noticed it during all the time I use OpenDKIM. ;-) > The write ability probably only matters if a key is being used for more than > one purpose... Personally, I can not imagine a single use case where a private key would be overwritten after the process of generating it. I only ever create keys manually, and in controlled environments. Even the sshd "feature" of generating a fresh set of keys on first startup is suspect to me. > Wait, what does this do then? > > UserID opendkim:postfix Now you made me check the manual page again, and it is good that you did. I thought the above settings only affected the socket file's owner and group, but "The process will be assigned all of the groups and primary group ID of the named userid unless an alternate group is specified." I just tested a modification here. Launching with "UserID opendkim" and then executing "chgrp postfix /run/opendkim/socket" in start_post() seems to work.
Michael and I discussed this, partly in my pull request and partly via email. I will add support for an additional, dedicated group that can be shared between OpenDKIM and an MTA. I'll also update the Wiki accordingly (Michael gave his OK).
(In reply to Ralph Seichter from comment #15) > Michael and I discussed this, partly in my pull request and partly via > email. I will add support for an additional, dedicated group that can be > shared between OpenDKIM and an MTA. I'll also update the Wiki accordingly > (Michael gave his OK). You may just want to punt on modifying the ebuild for a while. I've been thinking about it, and what we'd really like to do is 1. Create the dedicated "dkimsocket" group. 2. Create the "opendkim" user with primary group "dkimsocket". 3. Create the "opendkim" group. 4. Append the "opendkim" group to the "opendkim" user. None of those are really possible with our existing user.eclass. The "enewuser" function always creates a group named after the user and assigns it as the primary group (that's bug 512220, still open). And afterwards, the eclass doesn't provide any way to append extra groups to a user or to make one of them the primary group. And the reason we want to use the eclass is because... the "usermod" program isn't standard. Gentoo runs on systems where the syntax is slightly different, so if we put usermod commands directly into the ebuild, it might crash on those systems.
(In reply to Michael Orlitzky from comment #16) > You may just want to punt on modifying the ebuild for a while. Oh well, I only just read this comment of yours, on my way to bed (and after I have pushed a new ebuild version ten minutes ago). :-P > The "enewuser" function always creates a group named after the user > and assigns it as the primary group [...] Is that really a problem here? The line "UserID opendkim:dkimsocket" in opendkim.conf can be used to specify both user and group. Does it really hurt anybody if the OpenDKIM user's secondary group is used there?
(In reply to Ralph Seichter from comment #17) > (In reply to Michael Orlitzky from comment #16) > > > You may just want to punt on modifying the ebuild for a while. > Oh well, I only just read this comment of yours, on my way to bed (and after > I have pushed a new ebuild version ten minutes ago). :-P > > > The "enewuser" function always creates a group named after the user > > and assigns it as the primary group [...] > Is that really a problem here? The line "UserID opendkim:dkimsocket" in > opendkim.conf can be used to specify both user and group. Does it really > hurt anybody if the OpenDKIM user's secondary group is used there? This makes some kind of difference, but I'm not sure what. When you set "UserID opendkim:dkimsocket", the resulting process runs as only one group, namely dkimsocket. You can check by cat'ing /proc/$pid/status: $ cat /proc/26389/status Name: opendkim ... Uid: 108 108 108 108 Gid: 1007 1007 1007 1007 FDSize: 64 Groups: 1007 That's with "UserID opendkim:dkimsocket". When it's set to only "UserID opendkim" and dkimsocket is that user's primary group, it picks up both groups, dkimsocket and opendkim: $ cat /proc/26778/status Name: opendkim ... Uid: 108 108 108 108 Gid: 1007 1007 1007 1007 FDSize: 64 Groups: 108 1007 That might prevent the daemon from reading /var/lib/opendkim when using "UserID opendkim:dkimsocket", but I haven't tested it on a real mail server because I'm too tired to fix anything if I break it tonight.
(In reply to Michael Orlitzky from comment #18) > When you set "UserID opendkim:dkimsocket", the resulting process runs > as only one group [...] That might prevent the daemon from reading > /var/lib/opendkim when using "UserID opendkim:dkimsocket" Which brings us back https://bugs.gentoo.org/575666#c10 and me using opendkim:opendkim as the owner of mumble.key. Operationally that makes sense because nobody but opendkim needs access to the private key. From a security standpoint, if some adversary managed to run code as opendkim, he could read and replace the key data. Read access is unavoidable so no added concern there. Replacing the key data would mean DKIM signatures don't match DNS data anymore. That is not ideal, but what would the adversary stand to gain from this? Also, if DMARC is in the mix, the key data switch would be discovered when DMARC forensic/aggregate reports start rolling in, usually within 24 hours after the first signature failure. I think this is acceptable.
(In reply to Ralph Seichter from comment #19) > > Operationally that makes sense because nobody but opendkim needs access to > the private key. Would you swear to that? If we restrict readability to the file's owner, then we're painting ourselves into a corner if someone shows up with a weird use case where two users need to be able to read the key. IMO it makes more sense to use a network daemon in this scenario, but with more than one outgoing MTA, someone might conceivably share the keys between two instances of OpenDKIM running on different machines. If we insist that the key's owner is the only person who can read it, then there's no way to grant both daemons read-access to (for example) an NFS-mounted key.
(In reply to Michael Orlitzky from comment #20) > > Operationally that makes sense because nobody but opendkim > > needs access to the private key. > Would you swear to that? I have never come across a use case where any process other than the one actually generating DKIM signatures has required access to the DKIM private key. What would be the point of having a dedicated signing service but sharing the key around? > If we restrict readability to the file's owner, then we're painting > ourselves into a corner if someone shows up with a weird use case > where two users need to be able to read the key. Should this situation ever arise, and should the user be able to convince us that it is indeed a valid use case for more people than himself so that is worth actually supporting, we can make changes. Until then, I firmly believe YAGNI [1] applies. I propose to follow through with what I suggested, because I believe it covers the significant majority of installatios where OpenDKIM is being used. [1] https://martinfowler.com/bliki/Yagni.html
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=db3f841d797fc4d27befc756e1acf30dbb00035d commit db3f841d797fc4d27befc756e1acf30dbb00035d Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2019-03-31 21:11:47 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2019-03-31 21:12:22 +0000 mail-filter/opendkim: add "UMask 0117" to the config by default. Ralph and I have been discussing the best way to handle a local UNIX socket. One thing that we both agree on is that, regardless of the other details, the daemon should be running with a UMask of 0117 to create the socket group-writable but otherwise private. And since the opendkim(8) man page says that the UMask is used only for the socket, there's no reason we shouldn't add it to the default configuration. In other words, it doesn't hurt anything if you're *not* using a local socket. This is one fewer thing that we need to document. Bug: https://bugs.gentoo.org/575666 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-r9.ebuild | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
> I propose to follow through with what I suggested, because I believe it covers the significant majority of installatios where OpenDKIM is being used. If you're sure, I'll merge it; but everything (pkg_config, both elog messages, permissions on /var/lib/opendkim, the wiki...) needs to be updated again and users will have to migrate their permissions manually for the second time this week. Portage won't alter directory permissions/ownership on its own.
I have pondered the current behaviour of only running with the GID specified via "UserID user:group" instead of joining with the primary and supplementary groups defined by the system. Could it be considered a bug, I wondered. I had a look at the source code, but do not yet have a good idea for a fix (see opendkim.c around line 16363). Anyway, considering https://bugs.gentoo.org/606978#c4 ff. I feel like I should probably sit back and not work on a pull request for a while. ;-) Would like to pick up the ball yourself, Michael?
Klondike is working on bug 669612 soon, so I'll wait until after that. And then I'll give it a few more days, to make sure I don't dream up any more problems with the approach in https://bugs.gentoo.org/606978#c5. But then I can do that stuff in a new revision.
I opened https://github.com/trusteddomainproject/OpenDKIM/issues/40 . Maybe somebody upstream has something to offer. I will close my existing pull request for now. You merged the first commit which fixed https://bugs.gentoo.org/622604 , and that was the original cause for the PR.
This is as good as it's going to get... we have a working local socket example for both systemd and OpenRC now, and the ebuild points you to it: https://wiki.gentoo.org/wiki/OpenDKIM Moreover, all of this work is being upstreamed. Thanks everyone for your help.
