Re: Allowing OpenDMARC to send mail

[Matt Domsch]

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 <d.sastre.medina(a)gmail.com&gt;
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 <matt(a)domsch.com&gt; 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 -- selinux(a)lists.fedoraproject.org
> > To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
> > 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/[e-mail]...
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> >
>