Re: Allowing OpenDMARC to send mail

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

_______________________________________________
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