Bug 2125030

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.

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/

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.

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.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

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.

FEDORA-2023-9050c32c92 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-9050c32c92

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.

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.