Bug 891292

Summary: SELinux is preventing /usr/sbin/opendkim from using the dac_override capability
Product: [Fedora] Fedora Reporter: Vladislav Grigoryev <vg.aetera>
Component: opendkimAssignee: Steve Jenkins <steve>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: amessina, awilliam, baldur, dominick.grift, dwalsh, markrwatts, matt_domsch, mgrepl, mike, ncjeffgus, Per.t.Sjoholm, p.kwarts, stevejenkins, steve, vg.aetera
Target Milestone: ---Keywords: Reopened, Tracking
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: opendkim-2.10.1-2.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 918089 (view as bug list) Environment:
Last Closed: 2015-03-10 00:57:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 918089    
Attachments:
Description Flags
sealert text
none
ausearch output none

Description Vladislav Grigoryev 2013-01-02 13:45:36 UTC
Description of problem:
SELinux is preventing /usr/sbin/opendkim from using the dac_override capability.

*****  Plugin dac_override (91.4 confidence) suggests  ***********************

If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system
Then turn on full auditing to get path information about the offending file and generate the error again.
Do

Turn on full auditing
# auditctl -w /etc/shadow -p w
Try to recreate AVC. Then execute
# ausearch -m avc -ts recent
If you see PATH record check ownership/permissions on file, and fix it, 
otherwise report as a bugzilla.

*****  Plugin catchall (9.59 confidence) suggests  ***************************

If you believe that opendkim should have the dac_override capability by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep opendkim /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:dkim_milter_t:s0
Target Context                system_u:system_r:dkim_milter_t:s0
Target Objects                 [ capability ]
Source                        opendkim
Source Path                   /usr/sbin/opendkim
Port                          <Unknown>
Host                          srv08
Source RPM Packages           opendkim-2.7.2-1.fc17.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-165.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     srv08
Platform                      Linux srv08 3.6.9-2.fc17.x86_64 #1 SMP Tue Dec 4
                              13:26:04 UTC 2012 x86_64 x86_64
Alert Count                   6
First Seen                    2013-01-02 17:26:18 MSK
Last Seen                     2013-01-02 17:33:08 MSK
Local ID                      000a3062-cf1d-451f-9add-ac97f1985d59

Raw Audit Messages
type=AVC msg=audit(1357133588.822:31600): avc:  denied  { dac_override } for  pid=28676 comm="opendkim" capability=1  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability


type=AVC msg=audit(1357133588.822:31600): avc:  denied  { dac_read_search } for  pid=28676 comm="opendkim" capability=2  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability


type=SYSCALL msg=audit(1357133588.822:31600): arch=x86_64 syscall=open success=no exit=EACCES a0=1b29850 a1=0 a2=0 a3=378 items=0 ppid=28675 pid=28676 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=opendkim exe=/usr/sbin/opendkim subj=system_u:system_r:dkim_milter_t:s0 key=(null)

Hash: opendkim,dkim_milter_t,dkim_milter_t,capability,dac_override

audit2allow

#============= dkim_milter_t ==============
allow dkim_milter_t self:capability { dac_read_search dac_override };

audit2allow -R

#============= dkim_milter_t ==============
allow dkim_milter_t self:capability { dac_read_search dac_override };


How reproducible:
Always.

Actual results:
Jan  2 17:41:38 srv08 opendkim: /etc/opendkim/keys/default.private: open(): Permission denied
Jan  2 17:41:38 srv08 opendkim[28800]: Starting OpenDKIM Milter: opendkim: /etc/opendkim.conf: /etc/opendkim/keys/default.private: open(): Permission denied
Jan  2 17:41:38 srv08 opendkim[28800]: [FAILED]
Jan  2 17:41:38 srv08 systemd[1]: opendkim.service: control process exited, code=exited status=1
Jan  2 17:41:38 srv08 systemd[1]: Unit opendkim.service entered failed state.
Jan  2 17:41:39 srv08 setroubleshoot: SELinux is preventing /usr/sbin/opendkim from using the dac_override capability. For complete SELinux messages. run sealert -l 000a3062-cf1d-451f-9add-ac97f1985d59

Additional info:
# ls -ldZ /etc/opendkim /etc/opendkim/keys /etc/opendkim/keys/default.private 
drwxr-xr-x. root     opendkim system_u:object_r:etc_t:s0       /etc/opendkim
drwxr-xr-x. root     opendkim system_u:object_r:etc_t:s0       /etc/opendkim/keys
-rw-------. opendkim opendkim system_u:object_r:etc_t:s0       /etc/opendkim/keys/default.private

Comment 1 Vladislav Grigoryev 2013-01-02 13:58:24 UTC
# auditctl -w /etc/shadow -p w

# systemctl start opendkim.service
Job failed. See system journal and 'systemctl status' for details.

# ausearch -m avc -ts recent
----
time->Wed Jan  2 17:56:27 2013
type=PATH msg=audit(1357134987.983:31605): item=0 name="/etc/opendkim/keys/default.private" inode=1322110 dev=fd:01 mode=0100600 ouid=985 ogid=982 rdev=00:00 obj=system_u:object_r:etc_t:s0
type=CWD msg=audit(1357134987.983:31605):  cwd="/"
type=SYSCALL msg=audit(1357134987.983:31605): arch=c000003e syscall=2 success=no exit=-13 a0=25ab850 a1=0 a2=0 a3=378 items=1 ppid=29034 pid=29035 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="opendkim" exe="/usr/sbin/opendkim" subj=system_u:system_r:dkim_milter_t:s0 key=(null)
type=AVC msg=audit(1357134987.983:31605): avc:  denied  { dac_read_search } for  pid=29035 comm="opendkim" capability=2  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability
type=AVC msg=audit(1357134987.983:31605): avc:  denied  { dac_override } for  pid=29035 comm="opendkim" capability=1  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability

Comment 2 Miroslav Grepl 2013-01-02 14:28:39 UTC
Ok, good catch. The problem is with permissions on the default.private file

-rw-------. opendkim opendkim system_u:object_r:etc_t:s0       /etc/opendkim/keys/default.private

Comment 3 Daniel Walsh 2013-01-02 19:11:16 UTC
chown opendkim:root /etc/opendkim/keys/default.private
chmod g+r /etc/opendkim/keys/default.private

Would probably solve the problem.

Comment 4 Adam Williamson 2013-02-26 17:34:13 UTC
I'm seeing this - or something similar - and what Dan suggests doesn't solve it:

Feb 26 09:32:13 mailserver opendkim[1033]: Starting OpenDKIM Milter: opendkim: /etc/opendkim.conf: refile:/etc/opendkim/TrustedHosts: dkimf_db_open(): Permission denied
Feb 26 09:32:13 mailserver kernel: [  369.521726] type=1400 audit(1361899933.608:10): avc:  denied  { dac_override } for  pid=1036 comm="opendkim" capability=1  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability
Feb 26 09:32:13 mailserver kernel: [  369.521735] type=1400 audit(1361899933.608:11): avc:  denied  { dac_read_search } for  pid=1036 comm="opendkim" capability=2  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability
Feb 26 09:32:13 mailserver opendkim[1033]: [FAILED]

[root@mailserver adamw]# restorecon -vr /etc/opendkim/keys/
[root@mailserver adamw]# ls -lZ /etc/opendkim/keys/happyassassin.net/default
-rw-r-----. opendkim root unconfined_u:object_r:etc_t:s0   /etc/opendkim/keys/happyassassin.net/default

Comment 5 Adam Williamson 2013-02-28 03:12:28 UTC
Oh, and changing the permissions in that way is apparently a bad idea, as it causes opendkim to complain and fail to function:

Feb 27 19:02:34 mailserver opendkim[1057]: default._domainkey.happyassassin.net:
 key data is not secure
Feb 27 19:02:34 mailserver opendkim[1057]: 5E3F628747: error loading key 'defaul
t._domainkey.happyassassin.net'

Comment 6 Adam Williamson 2013-02-28 03:14:23 UTC
Oh, and hey, after starting opendkim in Permissive mode then switching to Enforcing mode, it doesn't work, as selinux refuses to let it access /dev/(u)random:

Feb 27 19:12:46 mailserver kernel: [121601.880343] type=1400 audit(1362021165.967:19): avc:  denied  { read } for  pid=4046 comm="opendkim" name="urandom" dev="devtmpfs" ino=4513 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
Feb 27 19:12:46 mailserver kernel: [121601.880399] type=1400 audit(1362021165.967:20): avc:  denied  { read } for  pid=4046 comm="opendkim" name="random" dev="devtmpfs" ino=4512 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file

Comment 7 Miroslav Grepl 2013-02-28 14:44:15 UTC
I am adding fixes.

Comment 8 Miroslav Grepl 2013-02-28 14:56:47 UTC
I also did clean up rawhide milter policy and moved rules from template to the milter_domains attribute.

Comment 9 Adam Williamson 2013-02-28 15:45:51 UTC
Thanks! Can we get a build soon? Running an unsecured mailserver is making me itchy :)

Comment 10 Adam Williamson 2013-03-04 20:21:19 UTC
Ping? I see F18 and Rawhide builds now, but no F17. No F17 selinux-policy has been built for a month.

Also, in the F18/Rawhide build changelogs, I see what looks like a fix for the urandom problem, but I don't see anything for the initial bug. Did I miss it in the changelog, or is there not a fix for that yet?

Comment 11 Miroslav Grepl 2013-03-05 13:08:46 UTC
Ah, I missed this bug. Doing a new F17 build.

Comment 12 Fedora Update System 2013-03-05 14:32:20 UTC
selinux-policy-3.10.0-168.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-168.fc17

Comment 13 Fedora Update System 2013-03-05 23:29:41 UTC
Package selinux-policy-3.10.0-168.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-168.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-3466/selinux-policy-3.10.0-168.fc17
then log in and leave karma (feedback).

Comment 14 Adam Williamson 2013-03-06 01:42:03 UTC
The initial bug is still not fixed. After installing that selinux-policy:

Mar  5 17:39:56 mailserver kernel: [634432.641455] type=1400 audit(1362533996.72
8:3026): avc:  denied  { dac_override } for  pid=21823 comm="opendkim" capability=1  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability
Mar  5 17:39:56 mailserver kernel: [634432.641482] type=1400 audit(1362533996.728:3026): avc:  denied  { dac_read_search } for  pid=21823 comm="opendkim" capability=2  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability
Mar  5 17:39:56 mailserver kernel: [634432.641558] type=1300 audit(1362533996.728:3026): arch=c000003e syscall=2 success=no exit=-13 a0=a8ed87 a1=0 a2=1b6 a3=238 items=0 ppid=21822 pid=21823 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="opendkim" exe="/usr/sbin/opendkim" subj=system_u:system_r:dkim_milter_t:s0 key=(null)
Mar  5 17:39:56 mailserver opendkim[21820]: Starting OpenDKIM Milter: opendkim: /etc/opendkim.conf: refile:/etc/opendkim/TrustedHosts: dkimf_db_open(): Permission denied
Mar  5 17:39:56 mailserver opendkim[21820]: [FAILED]
Mar  5 17:39:56 mailserver kernel: [634432.712800] type=1130 audit(1362533996.799:3027): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="opendkim" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

The urandom thing may be fixed, but the original bug is not.

Comment 15 Miroslav Grepl 2013-03-07 09:48:56 UTC
I opened a new bug for this issue on dkim-milter component.

Comment 16 Fedora Update System 2013-04-04 08:31:17 UTC
selinux-policy-3.10.0-169.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-169.fc17

Comment 17 Fedora Update System 2013-05-04 00:04:05 UTC
selinux-policy-3.10.0-169.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Michael Cronenworth 2013-05-15 03:28:05 UTC
This is not fixed, as Adam stated.


selinux-policy-3.11.1-92.fc18.noarch
opendkim-2.8.2-1.fc18.x86_64

Comment 19 Michael Cronenworth 2013-05-15 03:30:13 UTC
I do not have dkim-milter installed or in use.

Comment 20 Adam Williamson 2013-05-16 06:19:26 UTC
yeah, with selinux-policy 169, I'm still getting:

[19823.034944] type=1400 audit(1368685061.159:7): avc:  denied  { dac_override } for  pid=1427 comm="opendkim" capability=1  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability
[19823.034951] type=1400 audit(1368685061.159:8): avc:  denied  { dac_read_search } for  pid=1427 comm="opendkim" capability=2  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability

Comment 21 Miroslav Grepl 2013-05-16 10:31:00 UTC
Ok, this bug only fixed

Feb 27 19:12:46 mailserver kernel: [121601.880343] type=1400 audit(1362021165.967:19): avc:  denied  { read } for  pid=4046 comm="opendkim" name="urandom" dev="devtmpfs" ino=4513 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
Feb 27 19:12:46 mailserver kernel: [121601.880399] type=1400 audit(1362021165.967:20): avc:  denied  { read } for  pid=4046 comm="opendkim" name="random" dev="devtmpfs" ino=4512 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file

AVC msgs. 

dac_override issue should be fixed in the milter pkg.

Comment 22 Michael Cronenworth 2013-05-16 13:15:04 UTC
(In reply to comment #21)
> 
> dac_override issue should be fixed in the milter pkg.

Please read comment 19. I do not have any "milter pkg" installed. This bug is *not* fixed.

Comment 23 Miroslav Grepl 2013-05-16 13:18:57 UTC
What is your AVC msg?

Comment 24 Michael Cronenworth 2013-05-16 13:24:22 UTC
Created attachment 748828 [details]
sealert text

sealert output

Comment 25 Michael Cronenworth 2013-05-16 13:25:13 UTC
Created attachment 748829 [details]
ausearch output

I enabled full auditing, restarted opendkim, and ran ausearch.

$ ls -Z /etc/opendkim
drwxr-x---. root     opendkim system_u:object_r:etc_t:s0       keys
-rw-r-----. opendkim opendkim system_u:object_r:etc_t:s0       KeyTable
-rw-r-----. opendkim opendkim system_u:object_r:etc_t:s0       SigningTable
-rw-r-----. opendkim opendkim system_u:object_r:etc_t:s0       TrustedHosts

Comment 26 Miroslav Grepl 2013-05-16 15:00:05 UTC
Ok, still the same problem with permissions which has not been fixed by this bug.

Feb 27 19:12:46 mailserver kernel: [121601.880343] type=1400 audit(1362021165.967:19): avc:  denied  { read } for  pid=4046 comm="opendkim" name="urandom" dev="devtmpfs" ino=4513 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
Feb 27 19:12:46 mailserver kernel: [121601.880399] type=1400 audit(1362021165.967:20): avc:  denied  { read } for  pid=4046 comm="opendkim" name="random" dev="devtmpfs" ino=4512 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file

only these issues are fixed by this bug.

Comment 27 Adam Williamson 2013-05-16 16:26:15 UTC
mgrepl: "dac_override issue should be fixed in the milter pkg." - are we talking sendmail-milter here? or the specific milter that's causing the problem (which would be opendkim itself)?

Comment 28 Miroslav Grepl 2013-05-17 06:31:54 UTC
I see

comm="opendkim"

from AVC msgs.

What does

rpm -qf /etc/opendkim

Comment 29 Adam Williamson 2013-05-17 06:36:36 UTC
Dunno if that was meant for me, but, not surprisingly:

opendkim-2.8.2-1.fc17.x86_64

Comment 30 Steve Jenkins 2013-05-17 14:06:34 UTC
FYI - I submitted OpenDKIM 2.8.3 to the repos this morning. Shouldn't affect this bug, but just wanted to make anyone working on it aware of the updated version, just in case you wanted to test with the latest build.

Comment 31 Mark Watts 2013-07-29 17:12:41 UTC
Chaps; is this an SELinux issue or an opendkim issue?
I'm seeing the same problem on CentOS 6.4 with opendkim-2.6.7-1.el6.rf.x86_64 but I'm not sure whether I should be reporting it or upgrading the opendkim package?

Comment 32 Adam Williamson 2013-08-01 15:09:37 UTC
*** Bug 918089 has been marked as a duplicate of this bug. ***

Comment 33 Steve Jenkins 2013-08-03 03:57:21 UTC
FYI - OpenDKIM 2.8.4 was packaged just over a week ago, is still waiting in the EPEL Testing Repos, and is live in the Fedora stable repos.

No changes were make to the package specifically for this bug (since I'm still not sure what changes, if any, should be made to the package to help address this bug).

Just wanted to give anyone tracking this bug a heads up regarding the latest version.

Comment 34 Dietmar Kling 2013-10-11 15:52:36 UTC
Fedora 19 - Still a problem

in syslog:
SELinux is preventing /usr/sbin/opendkim from using the dac_override capability. For complete SELinux messages. run sealert -l b591cc14-3e1f-4600-8b71-0d21019f7aaf


 sealert -l b591cc14-3e1f-4600-8b71-0d21019f7aaf
SELinux is preventing /usr/sbin/opendkim from using the dac_override capability.

*****  Plugin dac_override (91.4 confidence) suggests  ***********************

If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system
Then turn on full auditing to get path information about the offending file and generate the error again.
Do

Turn on full auditing
# auditctl -w /etc/shadow -p w
Try to recreate AVC. Then execute
# ausearch -m avc -ts recent
If you see PATH record check ownership/permissions on file, and fix it,
otherwise report as a bugzilla.

*****  Plugin catchall (9.59 confidence) suggests  ***************************

If you believe that opendkim should have the dac_override capability by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep opendkim /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:dkim_milter_t:s0
Target Context                system_u:system_r:dkim_milter_t:s0
Target Objects                 [ capability ]
Source                        opendkim
Source Path                   /usr/sbin/opendkim
Port                          <Unknown>
Host                          xxxx
Source RPM Packages           opendkim-2.8.4-1.fc19.x86_64
Target RPM Packages
Policy RPM                    selinux-policy-3.12.1-74.8.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     xxxx
Platform                      Linux xxxx 3.11.1-200.fc19.x86_64
                              #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-10-11 17:41:48 CEST
Last Seen                     2013-10-11 17:41:48 CEST
Local ID                      b591cc14-3e1f-4600-8b71-0d21019f7aaf

Raw Audit Messages
type=AVC msg=audit(1381506108.902:28953): avc:  denied  { dac_override } for  pid=21265 comm="opendkim" capability=1  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability


type=AVC msg=audit(1381506108.902:28953): avc:  denied  { dac_read_search } for  pid=21265 comm="opendkim" capability=2  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability


type=SYSCALL msg=audit(1381506108.902:28953): arch=x86_64 syscall=open success=no exit=EACCES a0=1551c20 a1=0 a2=0 a3=7fffe4ab5f00 items=0 ppid=1 pid=21265 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=opendkim exe=/usr/sbin/opendkim subj=system_u:system_r:dkim_milter_t:s0 key=(null)

Hash: opendkim,dkim_milter_t,dkim_milter_t,capability,dac_override

Comment 35 Anthony Messina 2013-10-23 04:34:42 UTC
Ok, this basically boils down to the following files having the wrong permissions.  In the spec file, KeyTable, SigningTable and TrustedHosts are all set to mode 0640 with opendkim:opendkim ownership.

Chaning the ownership to root:opendkim solves the dac_override issue:

-rw-r-----. 1 root opendkim  427 Apr 11  2013 KeyTable
-rw-r-----. 1 root opendkim 1268 Apr 11  2013 SigningTable
-rw-r-----. 1 root opendkim  442 Apr 11  2013 TrustedHosts

Comment 36 Anthony Messina 2013-10-23 04:39:48 UTC
diff --git a/opendkim.spec b/opendkim.spec
index 0f7951a..06c04e2 100644
--- a/opendkim.spec
+++ b/opendkim.spec
@@ -331,9 +331,9 @@ rm -rf %{buildroot}
 %doc contrib/stats/README.%{name}-reportstats
 %config(noreplace) %{_sysconfdir}/%{name}.conf
 %config(noreplace) %{_sysconfdir}/tmpfiles.d/%{name}.conf
-%config(noreplace) %attr(640,%{name},%{name}) %{_sysconfdir}/%{name}/SigningTable
-%config(noreplace) %attr(640,%{name},%{name}) %{_sysconfdir}/%{name}/KeyTable
-%config(noreplace) %attr(640,%{name},%{name}) %{_sysconfdir}/%{name}/TrustedHosts
+%config(noreplace) %attr(640,root,%{name}) %{_sysconfdir}/%{name}/SigningTable
+%config(noreplace) %attr(640,root,%{name}) %{_sysconfdir}/%{name}/KeyTable
+%config(noreplace) %attr(640,root,%{name}) %{_sysconfdir}/%{name}/TrustedHosts
 %config(noreplace) %{_sysconfdir}/sysconfig/%{name}
 %{_sbindir}/*
 %{_mandir}/*/*

Comment 37 Michael Cronenworth 2013-10-23 13:18:17 UTC
You will also have to get the /etc/opendkim/keys directory set with the correct permissions as well.

Default:
-rw-------. 1 opendkim opendkim 887 May 14 21:28 foo.private
-rw-r--r--. 1 opendkim opendkim 319 May 14 21:28 foo.txt
-rw-------. 1 opendkim opendkim 887 Apr 28 23:04 default.private
-rw-r--r--. 1 opendkim opendkim 314 Apr 28 23:04 default.txt

Correct:
-rw-r-----. 1 root opendkim 887 May 14 21:28 foo.private
-rw-r--r--. 1 root opendkim 319 May 14 21:28 foo.txt
-rw-r-----. 1 root opendkim 887 Apr 28 23:04 default.private
-rw-r--r--. 1 root opendkim 314 Apr 28 23:04 default.txt

Now opendkim can start without any errors.

Comment 38 Matt Domsch 2013-11-16 03:04:21 UTC
Confirmed Michael's permissions work for me on EPEL 6 opendkim-2.8.4-1.el6.i686.

I did also have to setsebool -P allow_ypbind 1   to allow opendkim to bind to a unix socket.

type=SYSCALL msg=audit(1384568823.280:158309): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=b53fead0 a2=e588b0 a3=f items=0 ppid=1 pid=17076 auid=500 uid=497 gid=497 euid=497 suid=497 fsuid=497 egid=497 sgid=497 fsgid=497 tty=(none) ses=13503 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null)
type=AVC msg=audit(1384568823.280:158310): avc:  denied  { name_bind } for  pid=17076 comm="opendkim" src=7538 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=udp_socket

I'm using selinux-policy-targeted-3.7.19-195.el6_4.18.noarch

Comment 39 Daniel Walsh 2013-11-18 16:25:51 UTC
Matt are you running with NIS/YPbind?  If not, this is the wrong solution. since allow_ypbind weakens security quite abit, it eliminates controls on what ports a confined domain is allowed to listen/connect.

Comment 40 Matt Domsch 2013-11-18 16:32:57 UTC
Dan - no, I only did it because that's what audit2allow suggested.  Happy for a more correct solution.

Comment 41 Daniel Walsh 2013-11-18 18:03:08 UTC
semanage port -a -t milter_port_t 7538 

Would be the best solution, unless the port changes regurlarly?

Is this a port you chose?

Comment 42 Adam Williamson 2013-11-18 18:25:45 UTC
Unless we're talking about different things, the port used as an example in the docs in the opendkim package and in the stock /etc/opendkim.conf is 8891.

Comment 43 Michael Cronenworth 2013-11-18 18:33:44 UTC
Daniel & Adam, bug 1003177 was filed for the name_bind denial. A fix was pushed, but it does not solve the issue. A commit was not referenced so I'm not sure how that bug was attempted to be fixed.

OpenDKIM does DNS lookups (TXT record) for DKIM verification.

Comment 44 Steve Jenkins 2014-07-30 18:58:51 UTC
This bug is still open, but not sure what the status is, or if there's anything I can do on the package side to help resolve.

Is this bug with OpenDKIM or with SELinux?

Comment 45 Michael Cronenworth 2014-07-30 19:07:22 UTC
Steve, see comment 36 and comment 37. The file ownership issue is the only outstanding issue. I'm fairly certain the SELinux issues have been cleaned up as there are no denial messages in my log files.

Comment 46 Steve Jenkins 2014-07-30 19:11:43 UTC
AH - roger that. I am working on new builds today, so I can make those ownership fixes for sure.

Comment 47 Steve Jenkins 2014-07-30 19:49:25 UTC
Merely making the ownership changes on the directories from Comment 36 & 37 yeild the following (test host is tapper):

Jul 30 12:43:21 tapper opendkim[2394]: can't load key from /etc/opendkim/keys/example.com/default: Permission denied
Jul 30 12:43:21 tapper opendkim[2394]: AC42B140174: error loading key 'default._domainkey.example.com'

Changing the following lines in opendkim.conf:

# Attempt to become the specified user before starting operations.
UserID  opendkim:opendkim

to:

# Attempt to become the specified user before starting operations.
UserID  root

Allows the mailer to sign successfully, but I don't know if I'm opening another can of worms or potential security issues by having root run the service, rather than the opendkim user. I'll run this past the opendkim-dev group to get input.

Comment 48 Adam Williamson 2014-07-30 19:51:58 UTC
eek, no, don't run as root. Are you sure you did the ownership changes correctly? As I read them, the opendkim user has read access to all files, so it shouldn't be getting denials when doing a read.

Comment 49 Adam Williamson 2014-07-30 19:52:29 UTC
note the changes from c#37 are not purely ownership changes, but also permission changes. if you only change the ownership but don't change the permissions, yes, you'll get denials.

Comment 50 Steve Jenkins 2014-07-30 20:03:59 UTC
Yeah - I didn't think it should be run as root in a production environment.

Permissions and ownership of key files are currently as follows on my test server:

/etc/opendkim:
drwxr-xr-x 4 root opendkim 4096 Jul 24 12:34 keys
-rw-r----- 1 root opendkim  493 Jul 24 12:39 KeyTable
-rw-r----- 1 root opendkim  683 Jul 24 12:37 SigningTable
-rw-r----- 1 root opendkim  430 Jan  8  2013 TrustedHosts

/etc/opendkim/keys:
-rw------- 1 root opendkim  887 Mar  2  2013 default.private
-rw-r--r-- 1 root opendkim  315 Mar  2  2013 default.txt
drwxr-xr-x 2 root opendkim 4096 Jul 24 12:35 example.com

/etc/opendkim/keys/example.com:
-rw------- 1 root opendkim 887 Jul 24 12:35 default
-rw-r--r-- 1 root opendkim 316 Jul 24 12:35 default.txt

After restarting OpenDKIM and sending a mail from example.com, I get:

Jul 30 12:58:48 tapper opendkim[3124]: can't load key from /etc/opendkim/keys/example.com/default: Permission denied
Jul 30 12:58:48 tapper opendkim[3124]: 974FC141453: error loading key 'default._domainkey.example.com'
Jul 30 12:58:48 tapper postfix/cleanup[3148]: 974FC141453: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try again later; from=<root> to=<steve> proto=ESMTP helo=<tapper.example.com>

FYI - I have SELinux disabled on this server while I'm testing this.

Are any of my permissions or ownership different than ones you're testing with?

Comment 51 Adam Williamson 2014-07-30 20:06:42 UTC
you've got root.opendkim 0600 on default.private and example.com/default; of course a process running as opendkim can't read them.

in michael's layout (c#37) the key files have ownership root.opendkim with permissions *0640*.

Comment 52 Steve Jenkins 2014-07-30 20:07:45 UTC
Derp.

Just saw that as your comment came in.

Fixing now. :)

Comment 53 Steve Jenkins 2014-07-31 18:56:41 UTC
Running into some problems getting the default permissions on the keys set properly.

1) The spec file for the opendkim package creates and sets ownership/permissions for the /etc/opendkim directory and its files. No problems there. After installing the test package, I have:

drwxr-x---. 2 root opendkim 4096 Jul 31 10:55 keys
-rw-r-----. 1 root opendkim  339 Jul 31 10:55 KeyTable
-rw-r-----. 1 root opendkim 1221 Jul 31 10:55 SigningTable
-rw-r-----. 1 root opendkim  374 Jul 31 10:55 TrustedHosts

(as suggested in Comment 36).

2) The spec file also creates the /etc/opendkim/keys directory and sets its ownership to root:opendkim, but I'm still tinkering with the proper permissions. As of right now, I'm currently setting it to 770 in testing (open to suggestions if something else will help solve the remaining issues).

3) They default private and public keys, however, aren't created by the spec file. They are created when the opendkim service starts for the first time. On startup, /usr/sbin/opendkim-default-keygen checks for the existence of the default keys, and if they don't exist (or unless AUTOCREATE_DKIM_KEYS is set to NO in the options), it attempts to create and set ownership and permissions for the keys.

FYI - patch I'm applying to the opendkim-default-keygen.in in the package is:

https://github.com/stevejenkins/OpenDKIM-Fedora/blob/develop/PATCHES/opendkim.keygen-permissions.patch

The problem I'm having appears to be with the keygen script. I'm getting "operation not permitted" errors when it runs, because 

Errors generated by the default keygen script when trying to start opendkim:

Jul 31 11:46:11 fedora20 systemd: Starting DomainKeys Identified Mail (DKIM) Milter...
Jul 31 11:46:11 fedora20 opendkim-default-keygen: Generating default DKIM keys: chown: changing ownership of /etc/opendkim/keys: Operation not permitted
Jul 31 11:46:11 fedora20 opendkim-default-keygen: chown: changing ownership of /etc/opendkim/keys/default.private: Operation not permitted
Jul 31 11:46:11 fedora20 opendkim-default-keygen: chown: changing ownership of /etc/opendkim/keys/default.txt: Operation not permitted

After the attempted startup, /etc/opendkim/keys looks like:

-rw-r-----. 1 opendkim opendkim 891 Jul 31 11:46 default.private
-rw-r--r--. 1 opendkim opendkim 315 Jul 31 11:46 default.txt

If I manually delete the default keys and run /usr/sbin/opendkim-default-keygen from the command line as root, I get:

-rw-r-----. 1 root opendkim 887 Jul 31 11:52 default.private
-rw-r--r--. 1 root opendkim 315 Jul 31 11:52 default.txt

And then OpenDKIM starts fine (well, I do get a PID not readable message, which I've never seen before, but it seems to be running fine).

Jul 31 11:53:11 fedora20.example.com systemd[1]: Starting DomainKeys Identified Mail (DKIM) Milter...
Jul 31 11:53:11 fedora20.example.com systemd[1]: PID file /var/run/opendkim/opendkim.pid not readable (yet?) after start.
Jul 31 11:53:11 fedora20.example.com systemd[1]: Started DomainKeys Identified Mail (DKIM) Milter.
Jul 31 11:53:11 fedora20.example.com opendkim[2529]: OpenDKIM Filter v2.9.2 starting (args: -x /etc/opendkim.conf -P /var/run/opendkim/opendkim.pid)

So it seems that since default keygen script is run by the opendkim user at startup, it's not being allowed to change ownership of the default keys.

Any creative ideas to work around this, other than bagging the whole default key generation and forcing users to build and set ownership/permissions for their own keys?

Comment 54 Steve Jenkins 2014-08-04 19:21:43 UTC
After further consideration, I think the best option is to require the user to manually run the opendkim-default-keygen either as root or with sudo after the install, for two reasons:

1) It's the only way to ensure that the default keys get the proper ownership and permissions

2) It's likely that users will want to manually generate keys themselves anyway.

So unless someone comes up with a more elegant solution in the very near future, that's how I'm going to proceed.

Comment 55 Fedora Update System 2014-08-04 21:28:08 UTC
opendkim-2.9.2-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendkim-2.9.2-2.el6

Comment 56 Fedora Update System 2014-08-04 21:28:17 UTC
opendkim-2.9.2-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendkim-2.9.2-2.el5

Comment 57 Fedora Update System 2014-08-04 21:28:24 UTC
opendkim-2.9.2-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendkim-2.9.2-2.fc20

Comment 58 Fedora Update System 2014-08-04 21:28:33 UTC
opendkim-2.9.2-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/opendkim-2.9.2-2.fc19

Comment 59 Adam Williamson 2014-08-04 22:28:44 UTC
I was gonna suggest you could just run the keygen as root (not sure if that's against any policies) or check if it actually works with the opendkim ownership (I don't immediately see why it wouldn't, except for if opendkim artificially checks the ownership is as desired and quits if not). but asking people to run it manually doesn't sound terrible, should probably be documented in a README.fedora (or similar) though.

Comment 60 Steve Jenkins 2014-08-05 02:06:46 UTC
Adam:

Yes - opendkim checks to make sure ownership and permissions are "secure" for the private key, and barfs (arguably, as it should) if it isn't.

Agree about documenting the change, although I'd actually rather have root run the keygen script... but didn't know how to do that on startup, since the opendkim user is the one that owns the process.

Any ideas on how I could have root run the /usr/sbin/opendkim-default-keygen script when a user with permission to start the service does /bin/systemctl start opendkims.service ?

I've tested both as root and via sudo -- when I do /bin/systemctl start opendkims.service, I get the problem in Comment #53.

Thanks again for your help. :)

Comment 61 Fedora Update System 2014-08-07 11:47:09 UTC
Package opendkim-2.9.2-2.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing opendkim-2.9.2-2.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2124/opendkim-2.9.2-2.el5
then log in and leave karma (feedback).

Comment 62 Adam Williamson 2014-08-21 21:11:40 UTC
I usually start and stop services as root, I don't actually know the implications of doing it as a user. Ultimately, though, the job is presumably actually done by systemd, which is running as root. It might be best to ask a systemd dev for advice?

Comment 63 Michael Cronenworth 2014-12-09 17:52:32 UTC
This is a long overdue comment, but what you suggest is fine. It's no different than PostgreSQL requiring manual intervention to initialize a database after installation and prior to first service start.

An alternative would be to have opendkim.service depend on an init service that would run as root.

Comment 64 Adam Williamson 2014-12-10 20:57:04 UTC
well, I just updated to F21 with opendkim-2.9.2-3.fc21.x86_64 and it still fails on startup unless I temporarily set selinux to permissive. Where did we wind up on this one? I've forgotten.

Comment 65 Adam Williamson 2014-12-10 21:04:30 UTC
Oh, actually F21 seems worse :( I've now got this any time I try and send a mail:

Dec 10 12:57:33 mail.happyassassin.net opendkim[984]: can't initialize resolver: failed to initialize resolver
Dec 10 12:57:33 mail.happyassassin.net kernel: audit: type=1401 audit(1418245053.779:38): security_compute_sid:  invalid context system_u:unconfined_r:init_t:s0 for scontext=system_u:unconfined_r:init_t:s0 tcontext=system_u:unconfined_r:init_t:s0 tclass=unix_stream_socket

Comment 66 Adam Williamson 2014-12-10 21:14:31 UTC
When I set selinux to Permissive and send a mail, I get all of these:

Dec 10 13:13:43 mail.happyassassin.net kernel: audit: type=1400 audit(1418246023.330:42): avc:  denied  { accept } for  pid=984 comm="opendkim" laddr=127.0.0.1 lport=8891 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=tcp_socket permissive=1
Dec 10 13:13:43 mail.happyassassin.net kernel: audit: type=1400 audit(1418246023.331:43): avc:  denied  { setopt } for  pid=984 comm="opendkim" laddr=127.0.0.1 lport=8891 faddr=127.0.0.1 fport=58685 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=tcp_socket permissive=1
Dec 10 13:13:43 mail.happyassassin.net kernel: audit: type=1400 audit(1418246023.331:44): avc:  denied  { fork } for  pid=984 comm="opendkim" scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=process permissive=1
Dec 10 13:13:43 mail.happyassassin.net kernel: audit: type=1400 audit(1418246023.331:45): avc:  denied  { read } for  pid=1788 comm="opendkim" path="socket:[20713]" dev="sockfs" ino=20713 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=tcp_socket permissive=1
Dec 10 13:13:43 mail.happyassassin.net kernel: audit: type=1400 audit(1418246023.331:46): avc:  denied  { write } for  pid=1788 comm="opendkim" path="socket:[20713]" dev="sockfs" ino=20713 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=tcp_socket permissive=1
Dec 10 13:13:43 mail.happyassassin.net kernel: audit: type=1400 audit(1418246023.331:47): avc:  denied  { create } for  pid=1788 comm="opendkim" scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=unix_stream_socket permissive=1
Dec 10 13:13:43 mail.happyassassin.net kernel: audit: type=1400 audit(1418246023.592:48): avc:  denied  { search } for  pid=1788 comm="opendkim" name="etc" dev="vda3" ino=651522 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=1
Dec 10 13:13:43 mail.happyassassin.net kernel: audit: type=1400 audit(1418246023.592:49): avc:  denied  { search } for  pid=1788 comm="opendkim" name="happyassassin.net" dev="vda3" ino=823558 scontext=system_u:object_r:unlabeled_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=dir permissive=1
Dec 10 13:13:43 mail.happyassassin.net kernel: audit: type=1400 audit(1418246023.595:50): avc:  denied  { read } for  pid=1788 comm="opendkim" name="default" dev="vda3" ino=828740 scontext=system_u:object_r:unlabeled_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=1

Comment 67 Adam Williamson 2014-12-10 21:40:58 UTC
Hum, those went away with a reboot and relabel. Now I'm just back on the one where I have to set Permissive to start opendkim, but it works if I set it back to Enforcing after.

Comment 68 Adam Williamson 2015-01-08 17:28:33 UTC
Bah, and on another reboot, it seems to have issues with Enforcing again...

/var/log/audit/audit.log has tons of these:

type=PROCTITLE msg=audit(1420737874.004:3080): proctitle=2F7573722F7362696E2F6F7
0656E646B696D002D78002F6574632F6F70656E646B696D2E636F6E66002D50002F7661722F72756E2F6F70656E646B696D2F6F70656E646B696D2E706964
type=SELINUX_ERR msg=audit(1420737874.016:3081): security_compute_sid:  invalid context system_u:unconfined_r:init_t:s0 for scontext=system_u:unconfined_r:init_t:s0 tcontext=system_u:unconfined_r:init_t:s0 tclass=udp_socket
type=SELINUX_ERR msg=audit(1420737874.016:3081): security_compute_sid:  invalid context system_u:unconfined_r:init_t:s0 for scontext=system_u:unconfined_r:init_t:s0 tcontext=system_u:unconfined_r:init_t:s0 tclass=udp_socket
type=SYSCALL msg=audit(1420737874.016:3081): arch=c000003e syscall=41 success=yes exit=16 a0=2 a1=2 a2=0 a3=a1 items=0 ppid=1 pid=13265 auid=4294967295 uid=495 gid=494 euid=495 suid=495 fsuid=495 egid=494 sgid=494 fsgid=494 tty=(none) ses=4294967295 comm="opendkim" exe="/usr/sbin/opendkim" subj=system_u:unconfined_r:init_t:s0 key=(null)
type=PROCTITLE msg=audit(1420737874.016:3081): proctitle=2F7573722F7362696E2F6F70656E646B696D002D78002F6574632F6F70656E646B696D2E636F6E66002D50002F7661722F72756E2F6F70656E646B696D2F6F70656E646B696D2E706964
type=SELINUX_ERR msg=audit(1420737874.016:3082): security_compute_sid:  invalid context system_u:unconfined_r:init_t:s0 for scontext=system_u:unconfined_r:init_t:s0 tcontext=system_u:unconfined_r:init_t:s0 tclass=udp_socket
type=SELINUX_ERR msg=audit(1420737874.016:3082): security_compute_sid:  invalid context system_u:unconfined_r:init_t:s0 for scontext=system_u:unconfined_r:init_t:s0 tcontext=system_u:unconfined_r:init_t:s0 tclass=udp_socket
type=SYSCALL msg=audit(1420737874.016:3082): arch=c000003e syscall=41 success=yes exit=15 a0=a a1=2 a2=0 a3=a1 items=0 ppid=1 pid=13265 auid=4294967295 uid=495 gid=494 euid=495 suid=495 fsuid=495 egid=494 sgid=494 fsgid=494 tty=(none) ses=4294967295 comm="opendkim" exe="/usr/sbin/opendkim" subj=system_u:unconfined_r:init_t:s0 key=(null)

and all my mail operations yesterday failed. /var/log/maillog has these:

Jan  8 09:15:53 mail opendkim[1783]: can't initialize resolver: failed to initia
lize resolver

then it bounces all my incoming mail...thanks, opendkim.

Comment 69 Steve Jenkins 2015-01-08 17:38:08 UTC
I'll be updating the package for the 2.10 release of the OpenDKIM source next week. Anything I can do on the package side to help address this? Now is the time. :)

Comment 70 Michael Cronenworth 2015-01-08 17:45:17 UTC
I'm not seeing any issues on F20. Adam, you'll need to file a bug against selinux-policy. Definitely a regression in allowing DNS lookups.

Comment 71 Daniel Walsh 2015-01-08 17:59:13 UTC
THis is very strange and unrelated to the old issues.

I see you have some processes running as init_t type with the unconfined_r role.  This makes no sense.

ps -eZ | grep init_t

Comment 72 Adam Williamson 2015-01-08 18:21:18 UTC
As posted on IRC, that shows opendkim running as:

system_u:unconfined_r:init_t:s0 14046 ?        00:00:00 opendkim

ps aux shows:

opendkim 14046  0.0  0.2  99940  4740 ?        Ssl  10:18   0:00 /usr/sbin/opendkim -x /etc/opendkim.conf -P /var/run/opendkim/opendkim.pid

so it's running as the opendkim user, but not in the right context.

Comment 73 Adam Williamson 2015-01-08 20:42:52 UTC
Aha. I think I may have found the problem. It looks like long ago when dealing with the older selinux issues I had done something like 'semanage fcontext -a -t unconfined_exec_t /usr/sbin/opendkim' - I had a /etc/selinux/targeted/contexts/files/file_contexts.local with this line:

 /usr/sbin/opendkim    system_u:object_r:unconfined_exec_t:s0

I just did 'semanage fcontext -d /usr/sbin/opendkim' , 'restorecon -v /usr/sbin/opendkim' , restarted opendkim.service with selinux set Enforcing, and it seems to be working! It also started up OK on a clean VM when I dumped my whole opendkim config onto it and tried starting it up.

So was anyone else still having SELinux issues? If not I think we could possibly (finally) close this out, sorry for the mess.

Comment 74 Matt Domsch 2015-03-01 05:45:17 UTC
On EL6, I'm still getting name_bind failures.  using setsebool -P allow_ypbind 1 still resolves them.

[root@do1 cron]# rpm -q opendkim
opendkim-2.9.0-2.el6.i686

Comment 75 Fedora Update System 2015-03-04 04:09:03 UTC
opendkim-2.10.1-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-1.fc21

Comment 76 Fedora Update System 2015-03-04 04:09:12 UTC
opendkim-2.10.1-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-1.el6

Comment 77 Fedora Update System 2015-03-04 04:09:21 UTC
opendkim-2.10.1-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-1.fc22

Comment 78 Fedora Update System 2015-03-04 04:09:29 UTC
opendkim-2.10.1-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-1.el5

Comment 79 Fedora Update System 2015-03-04 04:09:37 UTC
opendkim-2.10.1-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-1.fc20

Comment 80 Fedora Update System 2015-03-04 04:09:45 UTC
opendkim-2.10.1-1.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-1.el7

Comment 81 Fedora Update System 2015-03-04 04:53:58 UTC
opendkim-2.10.1-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-2.fc21

Comment 82 Fedora Update System 2015-03-04 04:54:08 UTC
opendkim-2.10.1-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-2.el6

Comment 83 Fedora Update System 2015-03-04 04:54:19 UTC
opendkim-2.10.1-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-2.fc20

Comment 84 Fedora Update System 2015-03-04 04:54:30 UTC
opendkim-2.10.1-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-2.el5

Comment 85 Fedora Update System 2015-03-04 04:54:41 UTC
opendkim-2.10.1-2.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-2.el7

Comment 86 Fedora Update System 2015-03-04 04:54:51 UTC
opendkim-2.10.1-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/opendkim-2.10.1-2.fc22

Comment 87 Fedora Update System 2015-03-09 08:36:18 UTC
opendkim-2.10.1-2.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 88 Steve Jenkins 2015-03-09 14:30:07 UTC
Not sure if this bug should be closed yet...

Would appreciate testing from those who've experienced the issue to see if the combination of the latest OpenDKIM package + the latest updates to SELinux policies have addressed it (and for which platforms). Thanks!

Comment 89 Fedora Update System 2015-03-10 00:57:07 UTC
opendkim-2.10.1-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 90 Fedora Update System 2015-03-13 17:19:45 UTC
opendkim-2.10.1-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 91 Michael Cronenworth 2015-03-15 00:34:43 UTC
I have not seen any issues on F20 since the update.

Comment 92 Adam Williamson 2015-03-23 20:44:27 UTC
Me either, I think things are fine now. As mentioned in #c73 I had an old local selinux policy lying around, causing problems.

Comment 93 Fedora Update System 2015-03-25 19:56:46 UTC
opendkim-2.10.1-2.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 94 Fedora Update System 2015-03-25 19:57:09 UTC
opendkim-2.10.1-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 95 Fedora Update System 2015-03-25 20:06:07 UTC
opendkim-2.10.1-2.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.