Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1021183: opendkim: Opendkim complaining insecure keys by assumption
308 views
Skip to first unread message
Patrik Schindler
Oct 3, 2022, 8:50:03 AM10/3/22
to
Package: opendkim
Version: 2.11.0~beta2-4
Severity: normal
Each and every time, Opendkim wakes up by work from Postfix, it creates
a log entry:
key data is not secure: <filename>.private is in group 133 which has multiple
users (e.g., "postfix")
This issue has been existing since 2015 (when I added DKIM to my mailflow) and
the according Debian release.
Opendkim has its own group and for proper access rights from postfix, added
postfix to the opendkim group. If I don't set this, I get
Oct 3 14:17:33 myhost postfix/smtpd[123464]: warning: connect to Milter service unix:/var/run/opendkim/opendkim.sock: Permission denied
Setting RequireSafeKeys to "no" not prevent the message from appearing, but
just prevents Opendkim from exiting because of this condition.
I think that group rights should not trigger this behavior, but instead only
when "other" is allowed to read the private key.
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-18-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages opendkim depends on:
ii adduser 3.118
ii dns-root-data 2021011101
ii init-system-helpers 1.60
ii libbsd0 0.11.3-1
ii libc6 2.31-13+deb11u4
ii libdb5.3 5.3.28+dfsg1-0.8
ii libldap-2.4-2 2.4.57+dfsg-3+deb11u1
ii liblua5.1-0 5.1.5-8.1+b3
ii libmemcached11 1.0.18-4.2
ii libmilter1.0.1 8.15.2-22
ii libopendbx1 1.4.6-15
ii libopendkim11 2.11.0~beta2-4
ii librbl1 2.11.0~beta2-4
ii libssl1.1 1.1.1n-0+deb11u3
ii libunbound8 1.13.1-1
ii libvbr2 2.11.0~beta2-4
ii lsb-base 11.1.0
Versions of packages opendkim recommends:
ii opendkim-tools 2.11.0~beta2-4
opendkim suggests no packages.
-- Configuration Files:
/etc/dkimkeys/README.PrivateKeys [Errno 13] Permission denied: '/etc/dkimkeys/README.PrivateKeys'
/etc/opendkim.conf changed [not included]
-- no debconf information
Version: 2.11.0~beta2-4
Severity: normal
Each and every time, Opendkim wakes up by work from Postfix, it creates
a log entry:
key data is not secure: <filename>.private is in group 133 which has multiple
users (e.g., "postfix")
This issue has been existing since 2015 (when I added DKIM to my mailflow) and
the according Debian release.
Opendkim has its own group and for proper access rights from postfix, added
postfix to the opendkim group. If I don't set this, I get
Oct 3 14:17:33 myhost postfix/smtpd[123464]: warning: connect to Milter service unix:/var/run/opendkim/opendkim.sock: Permission denied
Setting RequireSafeKeys to "no" not prevent the message from appearing, but
just prevents Opendkim from exiting because of this condition.
I think that group rights should not trigger this behavior, but instead only
when "other" is allowed to read the private key.
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-18-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages opendkim depends on:
ii adduser 3.118
ii dns-root-data 2021011101
ii init-system-helpers 1.60
ii libbsd0 0.11.3-1
ii libc6 2.31-13+deb11u4
ii libdb5.3 5.3.28+dfsg1-0.8
ii libldap-2.4-2 2.4.57+dfsg-3+deb11u1
ii liblua5.1-0 5.1.5-8.1+b3
ii libmemcached11 1.0.18-4.2
ii libmilter1.0.1 8.15.2-22
ii libopendbx1 1.4.6-15
ii libopendkim11 2.11.0~beta2-4
ii librbl1 2.11.0~beta2-4
ii libssl1.1 1.1.1n-0+deb11u3
ii libunbound8 1.13.1-1
ii libvbr2 2.11.0~beta2-4
ii lsb-base 11.1.0
Versions of packages opendkim recommends:
ii opendkim-tools 2.11.0~beta2-4
opendkim suggests no packages.
-- Configuration Files:
/etc/dkimkeys/README.PrivateKeys [Errno 13] Permission denied: '/etc/dkimkeys/README.PrivateKeys'
/etc/opendkim.conf changed [not included]
-- no debconf information
David Bürgin
Oct 3, 2022, 9:30:03 AM10/3/22
to
Patrik Schindler:
on my installation (opendkim 2.11.0~beta2-5).
Some of my configuration bits below:
$ grep -i -e keyfile -e userid -e umask -e socket -e requiresafekeys /etc/opendkim.conf
KeyFile /etc/dkimkeys/2020.private
UserID opendkim
UMask 007
Socket local:/var/spool/postfix/opendkim/opendkim.sock
$ sudo ls -ld /etc/dkimkeys{,/2020.private}
drwx------ 2 opendkim opendkim 4096 Aug 25 2021 /etc/dkimkeys
-rw------- 1 opendkim opendkim 1679 Nov 20 2020 /etc/dkimkeys/2020.private
$ sudo ls -ld /var/spool/postfix/opendkim{,/opendkim.sock}
drwxr-x--- 2 opendkim opendkim 27 Sep 29 16:32 /var/spool/postfix/opendkim
srwxrwx--- 1 opendkim opendkim 0 Sep 29 16:32 /var/spool/postfix/opendkim/opendkim.sock
$ groups postfix | grep -o opendkim
opendkim
> Each and every time, Opendkim wakes up by work from Postfix, it creates
> a log entry:
>
> key data is not secure: <filename>.private is in group 133 which has multiple
> users (e.g., "postfix")
>
> This issue has been existing since 2015 (when I added DKIM to my mailflow) and
> the according Debian release.
>
> Opendkim has its own group and for proper access rights from postfix, added
> postfix to the opendkim group. If I don't set this, I get
>
> Oct 3 14:17:33 myhost postfix/smtpd[123464]: warning: connect to Milter service unix:/var/run/opendkim/opendkim.sock: Permission denied
>
> Setting RequireSafeKeys to "no" not prevent the message from appearing, but
> just prevents Opendkim from exiting because of this condition.
>
> I think that group rights should not trigger this behavior, but instead only
> when "other" is allowed to read the private key.
Can you include the steps to reproduce this? I don’t see this behaviour
> a log entry:
>
> key data is not secure: <filename>.private is in group 133 which has multiple
> users (e.g., "postfix")
>
> This issue has been existing since 2015 (when I added DKIM to my mailflow) and
> the according Debian release.
>
> Opendkim has its own group and for proper access rights from postfix, added
> postfix to the opendkim group. If I don't set this, I get
>
> Oct 3 14:17:33 myhost postfix/smtpd[123464]: warning: connect to Milter service unix:/var/run/opendkim/opendkim.sock: Permission denied
>
> Setting RequireSafeKeys to "no" not prevent the message from appearing, but
> just prevents Opendkim from exiting because of this condition.
>
> I think that group rights should not trigger this behavior, but instead only
> when "other" is allowed to read the private key.
on my installation (opendkim 2.11.0~beta2-5).
Some of my configuration bits below:
$ grep -i -e keyfile -e userid -e umask -e socket -e requiresafekeys /etc/opendkim.conf
KeyFile /etc/dkimkeys/2020.private
UserID opendkim
UMask 007
Socket local:/var/spool/postfix/opendkim/opendkim.sock
$ sudo ls -ld /etc/dkimkeys{,/2020.private}
drwx------ 2 opendkim opendkim 4096 Aug 25 2021 /etc/dkimkeys
-rw------- 1 opendkim opendkim 1679 Nov 20 2020 /etc/dkimkeys/2020.private
$ sudo ls -ld /var/spool/postfix/opendkim{,/opendkim.sock}
drwxr-x--- 2 opendkim opendkim 27 Sep 29 16:32 /var/spool/postfix/opendkim
srwxrwx--- 1 opendkim opendkim 0 Sep 29 16:32 /var/spool/postfix/opendkim/opendkim.sock
$ groups postfix | grep -o opendkim
opendkim
Patrik Schindler
Oct 3, 2022, 1:10:04 PM10/3/22
to
Hello David,
thanks for the quick response. After comparing your configuration to mine, I resolved the issue by trading possible security implications. See below.
Am 03.10.2022 um 15:15 schrieb David Bürgin <dbue...@gluet.ch>:
> Can you include the steps to reproduce this? I don’t see this behaviour on my installation (opendkim 2.11.0~beta2-5).
Will try to do so.
> Some of my configuration bits below:
>
> $ grep -i -e keyfile -e userid -e umask -e socket -e requiresafekeys /etc/opendkim.conf
> KeyFile /etc/dkimkeys/2020.private
> UserID opendkim
> UMask 007
> Socket local:/var/spool/postfix/opendkim/opendkim.sock
Mine is here.
UMask 002
Socket local:/var/run/opendkim/opendkim.sock
RequireSafeKeys no
UserID opendkim
> $ sudo ls -ld /etc/dkimkeys{,/2020.private}
> drwx------ 2 opendkim opendkim 4096 Aug 25 2021 /etc/dkimkeys
> -rw------- 1 opendkim opendkim 1679 Nov 20 2020 /etc/dkimkeys/2020.private
I do have multiple domains configured and thus use /etc/opendkim/domainname as base directory for keyfiles. Those belong to root:opendkim and are mode 2755.
-rw-r----- 1 root opendkim 887 Oct 26 2015 /etc/opendkim/pocnet.net/m201510.private
-rw-r--r-- 1 root opendkim 323 Oct 26 2015 /etc/opendkim/pocnet.net/m201510.txt
> $ sudo ls -ld /var/spool/postfix/opendkim{,/opendkim.sock}
> drwxr-x--- 2 opendkim opendkim 27 Sep 29 16:32 /var/spool/postfix/opendkim
> srwxrwx--- 1 opendkim opendkim 0 Sep 29 16:32 /var/spool/postfix/opendkim/opendkim.sock
-rw-r--r-- 1 root root 7 Oct 3 14:18 /var/run/opendkim/opendkim.pid
srwxrwxr-x 1 opendkim opendkim 0 Oct 3 14:18 /var/run/opendkim/opendkim.sock
> $ groups postfix | grep -o opendkim
> opendkim
# groups postfix | grep -o opendkim
opendkim
When I've configured opendkim for the first time, I tried to keep the key files belonging to root, so they couldn't be changed from opendkim itself — lessen attack surface.
After chown opendkim, and chmod 400 to the private key files, the warning message is — to be expected — gone, because there is no group access granted anymore. But there is a small — probably mostly theoretical — decrease in security, because key files now belong to the opendkim user, and a missing write bit can be overridden on owner match — having done this sometimes with vi and text files.
What's your opinion on that?
Thanks!
:wq! PoC
thanks for the quick response. After comparing your configuration to mine, I resolved the issue by trading possible security implications. See below.
Am 03.10.2022 um 15:15 schrieb David Bürgin <dbue...@gluet.ch>:
> Can you include the steps to reproduce this? I don’t see this behaviour on my installation (opendkim 2.11.0~beta2-5).
> Some of my configuration bits below:
>
> $ grep -i -e keyfile -e userid -e umask -e socket -e requiresafekeys /etc/opendkim.conf
> KeyFile /etc/dkimkeys/2020.private
> UserID opendkim
> UMask 007
> Socket local:/var/spool/postfix/opendkim/opendkim.sock
UMask 002
Socket local:/var/run/opendkim/opendkim.sock
RequireSafeKeys no
UserID opendkim
> $ sudo ls -ld /etc/dkimkeys{,/2020.private}
> drwx------ 2 opendkim opendkim 4096 Aug 25 2021 /etc/dkimkeys
> -rw------- 1 opendkim opendkim 1679 Nov 20 2020 /etc/dkimkeys/2020.private
-rw-r----- 1 root opendkim 887 Oct 26 2015 /etc/opendkim/pocnet.net/m201510.private
-rw-r--r-- 1 root opendkim 323 Oct 26 2015 /etc/opendkim/pocnet.net/m201510.txt
> $ sudo ls -ld /var/spool/postfix/opendkim{,/opendkim.sock}
> drwxr-x--- 2 opendkim opendkim 27 Sep 29 16:32 /var/spool/postfix/opendkim
> srwxrwx--- 1 opendkim opendkim 0 Sep 29 16:32 /var/spool/postfix/opendkim/opendkim.sock
srwxrwxr-x 1 opendkim opendkim 0 Oct 3 14:18 /var/run/opendkim/opendkim.sock
> $ groups postfix | grep -o opendkim
> opendkim
opendkim
When I've configured opendkim for the first time, I tried to keep the key files belonging to root, so they couldn't be changed from opendkim itself — lessen attack surface.
After chown opendkim, and chmod 400 to the private key files, the warning message is — to be expected — gone, because there is no group access granted anymore. But there is a small — probably mostly theoretical — decrease in security, because key files now belong to the opendkim user, and a missing write bit can be overridden on owner match — having done this sometimes with vi and text files.
What's your opinion on that?
Thanks!
:wq! PoC
0 new messages