Mailing List Archive: Ddclient sending emails on a Postfix server

Ddclient sending emails on a Postfix server

Dec 6, 2016, 3:29 AM

Post #1 of 4 (1393 views)

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

Re: Ddclient sending emails on a Postfix server [ In reply to ]

swift at gentoo

Dec 12, 2016, 12:03 PM

Post #2 of 4 (1379 views)

Permalink

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

Re: Ddclient sending emails on a Postfix server [ In reply to ]

selinux at sharp

Dec 14, 2016, 2:44 AM

Post #3 of 4 (1378 views)

Permalink

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

Re: Ddclient sending emails on a Postfix server [ In reply to ]

selinux at sharp

Dec 19, 2016, 12:26 PM

Post #4 of 4 (1361 views)

Permalink

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