Ddclient sending emails on a Postfix server

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Ddclient sending emails on a Postfix server

Robert Sharp

I am running ddclient on my router together with a relaying postfix server. Unfortunately I have configured ddclient to send emails when it has problems and I have had quite a few problems with AVCs as a result. I have figured most of them out now but there is one that I am stuck on.

It appears that sendmail (postfix variant) calls postdrop to actually deliver the emails, and using the postfix_domtrans_user_mail_handler(ddclient_t)
interface fixes most of the AVCs except two, and this is where I am stuck. Here is the ausearch output:

type=PROCTITLE msg=audit(1481006916.953:34919): proctitle=2F7573722F7362696E2F706F737464726F70002D72
type=PATH msg=audit(1481006916.953:34919): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=1478356 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t nametype=NORMAL
type=PATH msg=audit(1481006916.953:34919): item=0 name="/usr/sbin/postdrop" inode=818771 dev=fd:00 mode=0102711 ouid=0 ogid=208 rdev=00:00 obj=system_u:object_r:postfix_postdrop_exec_t nametype=NORMAL
type=CWD msg=audit(1481006916.953:34919):  cwd="/var/spool/postfix"
type=EXECVE msg=audit(1481006916.953:34919): argc=2 a0="/usr/sbin/postdrop" a1="-r"
type=SYSCALL msg=audit(1481006916.953:34919): arch=c000003e syscall=59 success=yes exit=0 a0=5b97747f30 a1=5b97748d70 a2=5b97747e50 a3=20 items=2 ppid=24964 pid=24965 auid=103 uid=103 gid=246 euid=103 suid=103 fsuid=103 egid=208 sgid=208 fsgid=208 tty=(none) ses=7 comm="postdrop" exe="/usr/sbin/postdrop" subj=system_u:system_r:postfix_postdrop_t key=(null)
type=AVC msg=audit(1481006916.953:34919): avc:  denied  { read write } for  pid=24965 comm="postdrop" path="socket:[2916040]" dev="sockfs" ino=2916040 scontext=system_u:system_r:postfix_postdrop_t tcontext=system_u:system_r:ddclient_t tclass=unix_stream_socket permissive=1
----
time->Tue Dec  6 06:48:36 2016
type=AVC msg=audit(1481006916.965:34920): avc:  denied  { getattr } for  pid=24965 comm="postdrop" path="socket:[2916040]" dev="sockfs" ino=2916040 scontext=system_u:system_r:postfix_postdrop_t tcontext=system_u:system_r:ddclient_t tclass=unix_stream_socket permissive=1

The command "postdrop -r" reads a message from stdin and writes a response to stdout. I am guessing these socket permissions are to do with piping stdout back to sendmail (running in ddclient_t), but I would have expected a fifo_file on a pipe rather than a socket? I can always check this with the postfix forum if needed.

I guess the "wrong" solution would be to require postfix_postdrop_t and allow it to access ddclient_t etc, but that would violate the rules, so either the postdrop interface is wrong or perhaps I should be doing this without a domain transition. That is how I started out and I had a whole lot more AVCs that are fixed by the transition, so I am tending towards the postdrop interface being not quite right?

Any views would be very much appreciated.

Best wishes,

Robert Sharp

Reply | Threaded
Open this post in threaded view
|

Re: Ddclient sending emails on a Postfix server

Sven Vermeulen
On Tue, Dec 06, 2016 at 11:29:21AM +0000, Robert Sharp wrote:

>    I am running ddclient on my router together with a relaying postfix
>    server. Unfortunately I have configured ddclient to send emails when it
>    has problems and I have had quite a few problems with AVCs as a result.
>    I have figured most of them out now but there is one that I am stuck
>    on.
>
>    It appears that sendmail (postfix variant) calls postdrop to actually
>    deliver the emails, and using the
>    postfix_domtrans_user_mail_handler(ddclient_t)
>    interface fixes most of the AVCs except two, and this is where I am
>    stuck. Here is the ausearch output:
>
[...]

>    type=AVC msg=audit(1481006916.953:34919): avc:  denied  { read write }
>    for  pid=24965 comm="postdrop" path="socket:[2916040]" dev="sockfs"
>    ino=2916040 scontext=system_u:system_r:postfix_postdrop_t
>    tcontext=system_u:system_r:ddclient_t tclass=unix_stream_socket
>    permissive=1
>    ----
>    time->Tue Dec  6 06:48:36 2016
>    type=AVC msg=audit(1481006916.965:34920): avc:  denied  { getattr }
>    for  pid=24965 comm="postdrop" path="socket:[2916040]" dev="sockfs"
>    ino=2916040 scontext=system_u:system_r:postfix_postdrop_t
>    tcontext=system_u:system_r:ddclient_t tclass=unix_stream_socket
>    permissive=1
>
>    The command "postdrop -r" reads a message from stdin and writes a
>    response to stdout. I am guessing these socket permissions are to do
>    with piping stdout back to sendmail (running in ddclient_t), but I
>    would have expected a fifo_file on a pipe rather than a socket? I can
>    always check this with the postfix forum if needed.

It's been a while that I did some Postfix work, which might be necessary to
debug this properly. The socket is owned by ddclient, is it possible that
"postdrop -r" input and/or output is redirected to a ddclient socket? From a
quick Google ddclient is shown as a Perl client, so some code scanning might
help to find out what the socket is about.

If so, then you might need to grant access (but might want to grant it only
to sock_file).

Wkr,
        Sven Vermeulen

Reply | Threaded
Open this post in threaded view
|

Re: Ddclient sending emails on a Postfix server

Robert Sharp
On 12/12/16 20:03, Sven Vermeulen wrote:
It's been a while that I did some Postfix work, which might be necessary to
debug this properly. The socket is owned by ddclient, is it possible that
"postdrop -r" input and/or output is redirected to a ddclient socket? From a
quick Google ddclient is shown as a Perl client, so some code scanning might
help to find out what the socket is about.

Yes, ddclient is one long perl script. I am not a perl diver myself but it is not difficult to track down the code. The "sub" routine "sendmail" uses the subroutine "pipecmd" to run /usr/bin/sendmail with command line parameters and a few lines of input. Pipecmd uses the open function, prefixing the command ("sendmail" in this case) with a pipe: open(*FD, "| sendmail"). Ddclient doesn't attempt to read stdout from the sendmail/postdrop call so presumably this is postdrop trying to read the pipe passed to it by sendmail?

Clearly sendmail is running in the ddclient domain (mta_sendmail_exec for some curious reason and not the sendmail interface) and presumably postdrop transitions to its own domain. This is where I think the problem lies and I am hoping it was my fault. At some point in trying to get sendmail to work I added "postfix_domtrans_user_mail_handler(ddclient_t)" but then found the answer was hiding in mta.if. This domtrans interface adds ddclient_t to the postfix_user_domtrans type attribute, which sesearch reveals to be one of the few ways of transitioning to the postfix_postdrop_t domain. That explains why postdrop has transitioned from sendmail (ddclient_t) and why it cannot access sendmail's pipe?

I am testing the policy without the domtrans call and with my fingers crossed.

Robert

Reply | Threaded
Open this post in threaded view
|

Re: Ddclient sending emails on a Postfix server

Robert Sharp
On 14/12/16 10:44, Robert Sharp wrote:
On 12/12/16 20:03, Sven Vermeulen wrote:
It's been a while that I did some Postfix work, which might be necessary to
debug this properly. The socket is owned by ddclient, is it possible that
"postdrop -r" input and/or output is redirected to a ddclient socket? From a
quick Google ddclient is shown as a Perl client, so some code scanning might
help to find out what the socket is about.

Yes, ddclient is one long perl script. I am not a perl diver myself but it is not difficult to track down the code. The "sub" routine "sendmail" uses the subroutine "pipecmd" to run /usr/bin/sendmail with command line parameters and a few lines of input. Pipecmd uses the open function, prefixing the command ("sendmail" in this case) with a pipe: open(*FD, "| sendmail"). Ddclient doesn't attempt to read stdout from the sendmail/postdrop call so presumably this is postdrop trying to read the pipe passed to it by sendmail?

Clearly sendmail is running in the ddclient domain (mta_sendmail_exec for some curious reason and not the sendmail interface) and presumably postdrop transitions to its own domain. This is where I think the problem lies and I am hoping it was my fault. At some point in trying to get sendmail to work I added "postfix_domtrans_user_mail_handler(ddclient_t)" but then found the answer was hiding in mta.if. This domtrans interface adds ddclient_t to the postfix_user_domtrans type attribute, which sesearch reveals to be one of the few ways of transitioning to the postfix_postdrop_t domain. That explains why postdrop has transitioned from sendmail (ddclient_t) and why it cannot access sendmail's pipe?

I am testing the policy without the domtrans call and with my fingers crossed.

Robert

Okay - just to apologise for rushing off down a complete rabbit hole. I ended up having to grant ddclient not much less the postfix admin rights, which rang a large alarm bell and caused me to reconsider the whole thing. I had started out trying to get sendmail into its own domain but failed. Looking harder at the various interfaces (there are 3: postfix, sendmail and mta) I realised the answer was staring straight at me: "mta_send_mail". Seems to be working without any AVCs now. I will file a bug to request this simple addition.

Robert