+++ This bug was initially created as a clone of Bug #891292 +++ 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 --- Additional comment from ArcFi on 2013-01-02 08:58:24 EST --- # 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 --- Additional comment from Miroslav Grepl on 2013-01-02 09:28:39 EST --- 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 --- Additional comment from Daniel Walsh on 2013-01-02 14:11:16 EST --- chown opendkim:root /etc/opendkim/keys/default.private chmod g+r /etc/opendkim/keys/default.private Would probably solve the problem. --- Additional comment from Adam Williamson on 2013-02-26 12:34:13 EST --- 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 --- Additional comment from Adam Williamson on 2013-02-27 22:12:28 EST --- 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' --- Additional comment from Adam Williamson on 2013-02-27 22:14:23 EST --- 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 --- Additional comment from Miroslav Grepl on 2013-02-28 09:44:15 EST --- I am adding fixes. --- Additional comment from Miroslav Grepl on 2013-02-28 09:56:47 EST --- I also did clean up rawhide milter policy and moved rules from template to the milter_domains attribute. --- Additional comment from Adam Williamson on 2013-02-28 10:45:51 EST --- Thanks! Can we get a build soon? Running an unsecured mailserver is making me itchy :) --- Additional comment from Adam Williamson on 2013-03-04 15:21:19 EST --- 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? --- Additional comment from Miroslav Grepl on 2013-03-05 08:08:46 EST --- Ah, I missed this bug. Doing a new F17 build.
I can confirm the following with selinux-policy-targeted-3.11.1-86.fc18.noarch, and opendkim-2.7.4-1.fc18.x86_64 I get the error in permissive mode when opendkim is trying to access /etc/opendkim/TrustedHosts. [root@host opendkim]# ls -alZ /etc/opendkim drwxr-xr-x. root opendkim system_u:object_r:etc_t:s0 . drwxr-xr-x. root root system_u:object_r:etc_t:s0 .. 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 time->Wed Apr 3 04:05:33 2013 type=PATH msg=audit(1364979933.237:200): item=0 name="/etc/opendkim/TrustedHosts" inode=58312857 dev=09:01 mode=0100640 ouid=989 ogid=987 rdev=00:00 obj=system_u:object_r:etc_t:s0 type=CWD msg=audit(1364979933.237:200): cwd="/" type=SYSCALL msg=audit(1364979933.237:200): arch=c000003e syscall=2 success=yes exit=3 a0=17b8da7 a1=0 a2=1b6 a3=238 items=1 ppid=3772 pid=3773 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) type=AVC msg=audit(1364979933.237:200): avc: denied { dac_override } for pid=3773 comm="opendkim" capability=1 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability ---- time->Wed Apr 3 04:05:33 2013 type=PATH msg=audit(1364979933.619:202): item=0 name="/var/lib/sepolgen/interface_info" inode=108740707 dev=09:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_lib_t:s0 type=CWD msg=audit(1364979933.619:202): cwd="/" type=SYSCALL msg=audit(1364979933.619:202): arch=c000003e syscall=2 success=yes exit=3 a0=22d2440 a1=0 a2=1b6 a3=238 items=1 ppid=612 pid=3788 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="audit2allow" exe="/usr/bin/python2.7" subj=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1364979933.619:202): avc: denied { open } for pid=3788 comm="audit2allow" path="/var/lib/sepolgen/interface_info" dev="md1" ino=108740707 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file type=AVC msg=audit(1364979933.619:202): avc: denied { read } for pid=3788 comm="audit2allow" name="interface_info" dev="md1" ino=108740707 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file
Yes, the problem is with permissions on /etc/opendkim/TrustedHosts.
(In reply to comment #2) > Yes, the problem is with permissions on /etc/opendkim/TrustedHosts. What permissions should it have, then? My opendkim service runs as the opendkim user.
I see from AVC that it runs as root type=SYSCALL msg=audit(1364979933.237:200): arch=c000003e syscall=2 success=yes exit=3 a0=17b8da7 a1=0 a2=1b6 a3=238 items=1 ppid=3772 pid=3773 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)
Ok, but it must drop privs or something: ~]# ps aufx|grep opendkim root 6637 0.0 0.0 109180 924 pts/2 S+ 07:39 0:00 | \_ grep --color=auto opendkim opendkim 3774 0.0 0.0 50420 1000 ? Ss 04:05 0:00 /usr/sbin/opendkim -x /etc/opendkim.conf -P /var/run/opendkim/opendkim.pid opendkim 3775 0.0 0.0 214408 2924 ? Sl 04:05 0:00 \_ /usr/sbin/opendkim -x /etc/opendkim.conf -P /var/run/opendkim/opendkim.pid ~]# id opendkim uid=989(opendkim) gid=987(opendkim) groups=987(opendkim),12(mail) Should I change the owner to root to avoid the dac_override issue?
The problem here is dkim_milder_t running as root (uid=0) is not allowed access. So the access is probably happening before you setuid.
(In reply to comment #6) > The problem here is dkim_milder_t running as root (uid=0) is not allowed > access. > > So the access is probably happening before you setuid. Does that mean that this bug should be filed against opendkim instead? I'd be happy to move it over there if that's the case.
I see that this bug is opened for Component: dkim-milter
(In reply to comment #8) > I see that this bug is opened for > > Component: > dkim-milter Oops! I forgot you cloned it already. My coffee maker broke this morning :( Thanks again.
No problem.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
*** This bug has been marked as a duplicate of bug 891292 ***