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