Re: Allowing OpenDMARC to send mail

Matt Domsch <[email protected]> Sun, 18 Sep 2022 20:08:05 -0400
Newsgroups gmane.linux.redhat.fedora.selinux
Message-ID <CAKzD2+=7_N2yQ9myuubeLvt9oKJB4Q=aqGPe_hx9yjD9nJU6Xw@mail.gmail.com>
Thanks all for the help.  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.

Thanks,
Matt

On Wed, Sep 14, 2022 at 10:05 AM Zdenek Pytela <[email protected]> wrote:

> The rules and interfaces exist in Fedoras and RHEL/Centos 9. If you need
> them in RHEL 8 right away, you can copy them from Fedora using something
> like
>
> ifndef(`mta_manage_queue',`
>        interface(`mta_manage_queue',`
>                gen_require(`
> ...
>
> On Mon, Sep 12, 2022 at 8:23 PM Matt Domsch <[email protected]> wrote:
>
>> selinux-policy-3.14.3-106.el8.noarch on Centos 8 Stream. So that may be
>> out of date in this instance.
>>
>> On Mon, Sep 12, 2022 at 4:58 AM Zdenek Pytela <[email protected]> wrote:
>>
>>> Matt,
>>>
>>> which selinux-policy package version is in place? In current Fedoras, we
>>> have these rules
>>>
>>> optional_policy(`
>>>        mta_manage_queue(dkim_milter_t)
>>>        mta_sendmail_exec(dkim_milter_t)
>>> ')
>>>
>>> which allow milter manage mqueue_spool_t and execute sendmail in
>>> dkim_milter_t domain.
>>>
>>> See also
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1770570
>>>
>>> On Sat, Sep 10, 2022 at 7:42 PM Matt Domsch <[email protected]> wrote:
>>>
>>>> Thanks David. I believe that is a figment of my attempts to solve this,
>>>> where I had that line on my local policy file.  The fact that it's getting
>>>> that far in domain dkim_milter_t is the problem, I believe.
>>>>
>>>>
>>>> On Sat, Sep 10, 2022 at 1:21 PM David Sastre <[email protected]>
>>>> wrote:
>>>>
>>>>> I'm not answering your question, but for what is worth, that AVC
>>>>> denial log run through audit2allow in Fedora 36 seems to be allowed by
>>>>> policy, i.e. the AVC denial should not trigger.
>>>>>
>>>>> $ echo 'type=AVC msg=audit(1662776560.507:10521833): avc:  denied  {
>>>>> create } for  pid=1385220 comm="sendmail" name="df28A2Meeh1385220"
>>>>> scontext=system_u:system_r:dkim_milter_t:s0
>>>>> tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=file permissive=0' |
>>>>> sudo audit2allow
>>>>>
>>>>> #============= dkim_milter_t ==============
>>>>>
>>>>> #!!!! This avc is allowed in the current policy
>>>>> allow dkim_milter_t mqueue_spool_t:file create;
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Sep 10, 2022 at 3:37 PM Matt Domsch <[email protected]> wrote:
>>>>>
>>>>>> OpenDMARC (Domain-based Message Authentication, Reporting &
>>>>>> Conformance)
>>>>>> provides an open source library that implements the DMARC verification
>>>>>> service plus a milter-based filter application that can plug in to any
>>>>>> milter-aware MTA, including sendmail, Postfix, or any other MTA that
>>>>>> supports
>>>>>> the milter protocol.
>>>>>>
>>>>>> One feature of OpenDMARC is that i can send email to domains who have
>>>>>> specified in their DMARC DNS record that they wish to receive reports
>>>>>> (either aggregate or forensic) from mail servers when a message claiming to
>>>>>> originate from their mail domain has been received. This allows sending
>>>>>> mail servers to possibly adjust their mail sending practices to ensure all
>>>>>> mail they legitimately send are marked as such, and all mail sent as a
>>>>>> spoof of their domain then be blocked by filters.
>>>>>>
>>>>>> opendmarc runs in selinux domain dkim_milter_t (I never got around to
>>>>>> asking for a separate dmarc_milter_t domain), and uses
>>>>>> popen("/usr/sbin/sendmail -t ...") to send its aggregate or forensic
>>>>>> report.  selinux policy currently prohibits this behavior.
>>>>>>
>>>>>> I have been trying to write a custom policy that would allow
>>>>>> opendmarc to make the transition to sendmail_t, but have been unsuccessful,
>>>>>> hence this plea for help.
>>>>>>
>>>>>> #============= dkim_milter_t ==============
>>>>>> allow dkim_milter_t self:process setrlimit;  # opendmarc calls
>>>>>> setrlimit()
>>>>>> allow dkim_milter_t shell_exec_t:file { execute_no_trans map
>>>>>> entrypoint }; # opendmarc calls popen() which invokes /bin/sh
>>>>>> allow dkim_milter_t sendmail_exec_t:file { entrypoint execute getattr
>>>>>> open read map }; # invokes sendmail which has this file type
>>>>>> allow dkim_milter_t sendmail_t : process transition; # allow the
>>>>>> transition to sendmail_t
>>>>>> type_transition dkim_milter_t sendmail_exec_t : process sendmail_t; #
>>>>>>
>>>>>> However, once sendmail is running and tries to create its queue files
>>>>>> in /var/spool/mqueue which has type mqueue_spool_t, the audit logs indicate
>>>>>> it's still running as dkim_milter_t which doesn't have permissions to
>>>>>> manage that directory (nor should it - that's sendmail's job).
>>>>>>
>>>>>> type=AVC msg=audit(1662776560.507:10521833): avc:  denied  { create }
>>>>>> for  pid=1385220 comm="sendmail" name="df28A2Meeh1385220"
>>>>>> scontext=system_u:system_r:dkim_milter_t:s0
>>>>>> tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=file permissive=0
>>>>>>
>>>>>> What do I need to do to get opendmarc to be running in sendmail_t
>>>>>> automatically following the popen()?
>>>>>>
>>>>>> Also filed in
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=2125030
>>>>>>
>>>>>> Thanks,
>>>>>> Matt
>>>>>>
>>>>>> _______________________________________________
>>>>>> selinux mailing list -- [email protected]
>>>>>> To unsubscribe send an email to [email protected]
>>>>>> Fedora Code of Conduct:
>>>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>>> List Guidelines:
>>>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>>> List Archives:
>>>>>> https://lists.fedoraproject.org/archives/list/[email protected]
>>>>>> Do not reply to spam, report it:
>>>>>> https://pagure.io/fedora-infrastructure/new_issue
>>>>>>
>>>>> _______________________________________________
>>>> selinux mailing list -- [email protected]
>>>> To unsubscribe send an email to [email protected]
>>>> Fedora Code of Conduct:
>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List Archives:
>>>> https://lists.fedoraproject.org/archives/list/[email protected]
>>>> Do not reply to spam, report it:
>>>> https://pagure.io/fedora-infrastructure/new_issue
>>>>
>>>
>>>
>>> --
>>>
>>> Zdenek Pytela
>>> Security SELinux team
>>>
>>
>
> --
>
> Zdenek Pytela
> Security SELinux team
>

_______________________________________________
selinux mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue