Allowing OpenDMARC to send mail

[Matt Domsch]

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

[David Sastre]

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
>

[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
> >
>

[Zdenek Pytela]

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 <matt(a)domsch.com&gt; 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 <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
> >>
> > _______________________________________________
>  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
>  

-- 

Zdenek Pytela
Security SELinux team

[Matt Domsch]

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 <zpytela(a)redhat.com&gt; 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 <matt(a)domsch.com&gt; 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 <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
> >>>
> >> _______________________________________________
> > 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
> >
>
>
>  --
>
>  Zdenek Pytela
>  Security SELinux team
>

[Zdenek Pytela]

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 <matt(a)domsch.com&gt; 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 <zpytela(a)redhat.com&gt; 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 <matt(a)domsch.com&gt; 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 <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
> >>>>
> >>> _______________________________________________
> >> 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
> >>
> >
> >
> > --
> >
> > Zdenek Pytela
> > Security SELinux team
> >
>  
-- 

Zdenek Pytela
Security SELinux team

[Matt Domsch]

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 <zpytela(a)redhat.com&gt; 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 <matt(a)domsch.com&gt; 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 <zpytela(a)redhat.com&gt; 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 <matt(a)domsch.com&gt; 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
> <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
> >>>>>
> >>>> _______________________________________________
> >>> 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
> >>>
> >>
> >>
> >> --
> >>
> >> Zdenek Pytela
> >> Security SELinux team
> >>
> >
>
>  --
>
>  Zdenek Pytela
>  Security SELinux team
>