Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 891292
Summary: | SELinux is preventing /usr/sbin/opendkim from using the dac_override capability | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Vladislav Grigoryev <vg.aetera> | ||||||
Component: | opendkim | Assignee: | Steve Jenkins <steve> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | rawhide | CC: | 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
Vladislav Grigoryev
2013-01-02 13:45:36 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 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 chown opendkim:root /etc/opendkim/keys/default.private chmod g+r /etc/opendkim/keys/default.private Would probably solve the problem. 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 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' 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 I am adding fixes. I also did clean up rawhide milter policy and moved rules from template to the milter_domains attribute. Thanks! Can we get a build soon? Running an unsecured mailserver is making me itchy :) 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? Ah, I missed this bug. Doing a new F17 build. 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 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). 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. I opened a new bug for this issue on dkim-milter component. 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 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. This is not fixed, as Adam stated. selinux-policy-3.11.1-92.fc18.noarch opendkim-2.8.2-1.fc18.x86_64 I do not have dkim-milter installed or in use. 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 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. (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. What is your AVC msg? Created attachment 748828 [details]
sealert text
sealert output
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
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. 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)? I see comm="opendkim" from AVC msgs. What does rpm -qf /etc/opendkim Dunno if that was meant for me, but, not surprisingly: opendkim-2.8.2-1.fc17.x86_64 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. 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? *** Bug 918089 has been marked as a duplicate of this bug. *** 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. 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 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 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}/*/* 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. 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 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. Dan - no, I only did it because that's what audit2allow suggested. Happy for a more correct solution. semanage port -a -t milter_port_t 7538 Would be the best solution, unless the port changes regurlarly? Is this a port you chose? 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. 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. 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? 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. AH - roger that. I am working on new builds today, so I can make those ownership fixes for sure. 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. 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. 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. 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? 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*. Derp. Just saw that as your comment came in. Fixing now. :) 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? 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. 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 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 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 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 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. 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. :) 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). 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? 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. 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. 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 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 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. 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. 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. :) 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. 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 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. 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. 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 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 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 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 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 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 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 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 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 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 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 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 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 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. 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! 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. 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. I have not seen any issues on F20 since the update. Me either, I think things are fine now. As mentioned in #c73 I had an old local selinux policy lying around, causing problems. 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. 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. 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. |