Bug 2125030 - opendkim and opendmarc sendmail policy request
Summary: opendkim and opendmarc sendmail policy request
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 38
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-07 19:32 UTC by Matt Domsch
Modified: 2023-06-18 01:29 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-38.17-1.fc38
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-06-18 01:29:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 1737 0 None open Allow dkim-milter domain transition to sendmail 2023-06-14 10:04:07 UTC
Red Hat Bugzilla 1716937 0 medium CLOSED SELinux prevents opendkim from executing /usr/bin/bash 2023-06-14 10:04:07 UTC

Internal Links: 2253647

Description Matt Domsch 2022-09-07 19:32:31 UTC
Description of problem:
opendmarc has the ability to invoke sendmail to send reports back to domain DMARC owners. Coming from selinux context dkim_milter_t, it invokes popen('/usr/sbin/sendmail -t ...'). This requires the ability to invoke /bin/bash via popen, which then needs to call sendmail.  The following module addresses the first four failures, but isn't enough.

require {
        type shell_exec_t;
        type dkim_milter_t;
        class file { execute execute_no_trans map};
}

#============= dkim_milter_t ==============
allow dkim_milter_t shell_exec_t:file execute;
allow dkim_milter_t shell_exec_t:file execute_no_trans;
allow dkim_milter_t shell_exec_t:file map;

still results in:

 avc:  denied  { getattr } for  pid=1279292 comm="sh" path="/usr/sbin/sendmail.sendmail" dev="vda1" ino=12747009 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file permissive=0


Version-Release number of selected component (if applicable):
1.4.2-5

How reproducible:
always

Steps to Reproduce:
1. run opendmarc with configuration option FailureReports true
2. receive an email that has DMARC policy ruf= or rua= set.
3. watch sendmail try to be started to send a message, and fail.

Actual results:
mail not sent from opendmarc

Expected results:
mail sent

Additional info:

Comment 1 Matt Domsch 2022-09-08 18:32:32 UTC
I've gotten all the AVCs to stop so far with the following module:
module my-opendmarc 1.0;

require {
        type shell_exec_t;
        type dkim_milter_t;
        type mqueue_spool_t;
        type sendmail_exec_t;
        type fs_t;
        class file { execute execute_no_trans map getattr open read};
        class process setrlimit;
        class dir { getattr search };
        class filesystem getattr;
}

#============= dkim_milter_t ==============
allow dkim_milter_t shell_exec_t:file { execute execute_no_trans map};
allow dkim_milter_t sendmail_exec_t:file { execute execute_no_trans getattr open read map };
allow dkim_milter_t mqueue_spool_t:dir { getattr search };
allow dkim_milter_t self:process setrlimit;
allow dkim_milter_t fs_t:filesystem getattr;

but I'm still getting what I think are systemd-imposed restrictions writing spool files. I'll try systemd service ProtectSystem=full and other changes there now that selinux seems to be out of the way, to make it work.

Comment 2 Matt Domsch 2022-09-10 13:43:44 UTC
Needs a different approach. Rather than trying to give dkim_milter_t the same sets of permissions as sendmail itself may need, we need to transition to the sendmail_t domain. But I haven't figured out how to do it. Plea for help sent to selinux@lists.

https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/thread/J4VROWRPNOWNZAYPYBWH3HISUJUKNKHI/

Comment 3 Matt Domsch 2022-09-19 23:40:57 UTC
My solution on centos 8 stream is:

module my-opendmarc 1.0;
require {
        type dkim_milter_t;
        type shell_exec_t;
        type sendmail_exec_t;
        type sendmail_t;
        class process { setrlimit transition  sigchld };
        class file { execute map entrypoint getattr open read ioctl execute_no_trans };
        class dir { getattr search open };
        class lnk_file { getattr read };
        class fd use;
        class fifo_file { getattr read write append ioctl lock };
}
#============= dkim_milter_t ==============
allow dkim_milter_t self:process setrlimit;
allow dkim_milter_t shell_exec_t:file { execute execute_no_trans map };
mta_sendmail_domtrans(dkim_milter_t, sendmail_t)



which yields a transition path as follows:
# sepolicy transition -s dkim_milter_t
dkim_milter_t @ sendmail_exec_t --> sendmail_t
dkim_milter_t @ abrt_helper_exec_t --> abrt_helper_t
dkim_milter_t @ postfix_postdrop_t --> sendmail_t
dkim_milter_t @ exim_exec_t --> sendmail_t
dkim_milter_t @ courier_exec_t --> sendmail_t

which uses sendmail_exec_t to get to sendmail_t and be happy.

I don't have a mail server on Fedora, but I don't see any transition policy for dkim_milter_t that's allowed besides for abrt, so I'd believe Fedora could benefit from such a policy as well. OpenDKIM can also send mail, but I haven't had a program configured for it to send mail. I'll be trying that next, and since it also uses dkim_milter_t, should likewise follow this (new) policy.

Comment 4 Matt Domsch 2022-09-26 02:16:19 UTC
I request selinux-policy add a policy for use by opendkim and opendmarc along the lines of the policy file noted above. This policy allows both programs to use setrlimit and to popen() sendmail for purposes of sending mail when started as a milter.

Comment 5 Ben Cotton 2023-02-07 15:12:41 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 6 Zdenek Pytela 2023-06-14 10:04:07 UTC
Executing shell is allowed in Fedora since https://bugzilla.redhat.com/show_bug.cgi?id=1716937
so adding now the transition to the sendmail domain.

Comment 7 Fedora Update System 2023-06-15 20:24:29 UTC
FEDORA-2023-9050c32c92 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-9050c32c92

Comment 8 Fedora Update System 2023-06-16 04:34:55 UTC
FEDORA-2023-9050c32c92 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-9050c32c92`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-9050c32c92

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2023-06-18 01:29:48 UTC
FEDORA-2023-9050c32c92 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.