tlsproxy: TLS handshake failed for service=smtp

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

tlsproxy: TLS handshake failed for service=smtp

Tomas Habarta
Hello,

I would like to ask about the following encountered during selinux testing:
* currently running 3.5.8 self-compiled (no vendor packaging), centos8 (selinux disabled)
* target platform centos8 (same configuration but selinux enabled)

With smtp_tls_connection_reuse = yes, all works ok on a current platform. The same configuration on the target platform fails to set up a TLS connection to a peer via tlsproxy (it's ok directly via smtp when reuse = no).
Unfortunately, there are no messages indicating any selinux or another denials at all, so I have no clue what next to pursue on selinux side, but setting selinux to permissive mode definitely makes the difference. When comparing outputs for both cases (tlsproxy with -v switch) all is the same up to "setting up TLS connection to" stage, where in case:

selinux disabled:
transaction finishes ok

selinux enabled:
transaction fails with:

tlsproxy[23256]: warning: tlsp_get_fd_event: receive remote SMTP peer file descriptor: Success
tlsproxy[23256]: TLS handshake failed for service=smtp peer=[10.25.41.35]:25
tlsproxy[23256]: connection closed fd 128
tlsproxy[23256]: DISCONNECT [10.25.41.35]:25

The "warning" message is not logged in case of selinux disabled -- might be that application logic takes a different path as a side effect of something that is affected by selinux state?
It's not crucial, as a single-purpose server, it's gonna get an exception, but I am just curious what the culprit is here -- perhaps anyone with understanding what the warning message may indicate could shade some light on this.



Many thanks,
Tomas
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy: TLS handshake failed for service=smtp

Viktor Dukhovni
On Mon, Mar 29, 2021 at 06:36:10PM +0200, Tomas Habarta wrote:

> selinux enabled:
> transaction fails with:
>
> tlsproxy[23256]: warning: tlsp_get_fd_event: receive remote SMTP peer file descriptor: Success
> tlsproxy[23256]: TLS handshake failed for service=smtp peer=[10.25.41.35]:25
> tlsproxy[23256]: connection closed fd 128
> tlsproxy[23256]: DISCONNECT [10.25.41.35]:25

Looks like file-descriptor passing is broken under SELinux.  Perhaps an
incomplete application sandbox profile.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy: TLS handshake failed for service=smtp

Wietse Venema
In reply to this post by Tomas Habarta
Tomas Habarta:
> Hello,
>
> I would like to ask about the following encountered during selinux testing:
> * currently running 3.5.8 self-compiled (no vendor packaging), centos8 (selinux disabled)
> * target platform centos8 (same configuration but selinux enabled)

Best bet is to strace the tlsproxy process (see DEBUG_README.html)
and see what syscall is failing.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy: TLS handshake failed for service=smtp

Tomas Habarta
On Mon, Mar 29, 2021 at 01:22:38PM -0400, Wietse Venema wrote:

> Tomas Habarta:
> > Hello,
> >
> > I would like to ask about the following encountered during selinux testing:
> > * currently running 3.5.8 self-compiled (no vendor packaging), centos8 (selinux disabled)
> > * target platform centos8 (same configuration but selinux enabled)
>
> Best bet is to strace the tlsproxy process (see DEBUG_README.html)
> and see what syscall is failing.
>
> Wietse

Thanks for the hint, it indeed seems to be a problem with fd as Viktor noticed (6663 - selinux enabled, 7141 - disabled).
For 6663 there's immediate close after recvmsg:
[6663]: close(128)                              = 0
whereas 7141 goes on further...

Have no idea what it means, but I am sure you do. Will be happy to provide more if that helps.


Thanks!
Tomas



[6663]: poll([{fd=128, events=POLLIN}], 1, 5000) = 1 ([{fd=128, revents=POLLIN}])
[7141]: poll([{fd=128, events=POLLIN}], 1, 5000) = 1 ([{fd=128, revents=POLLIN}])

[6663]: read(128, "remote_endpoint\0[10.25.41.35]:2"..., 4096) = 1283
[7141]: read(128, "remote_endpoint\0[10.25.41.35]:2"..., 4096) = 1283

[6663]: poll([{fd=128, events=POLLOUT}], 1, 5000) = 1 ([{fd=128, revents=POLLOUT}])
[7141]: poll([{fd=128, events=POLLOUT}], 1, 5000) = 1 ([{fd=128, revents=POLLOUT}])

[6663]: write(128, "status\0001\0\0", 10)       = 10
[7141]: write(128, "status\0001\0\0", 10)       = 10

[6663]: alarm(3)                                = 3
[7141]: alarm(3)                                = 3

[6663]: epoll_wait(11, [{EPOLLIN, {u32=128, u64=94901597372544}}], 100, 5000) = 1
[7141]: epoll_wait(11, [{EPOLLIN, {u32=128, u64=94643899334784}}], 100, 5000) = 1

[6663]: epoll_ctl(11, EPOLL_CTL_DEL, 128, 0x7ffc2cd0e32c) = 0
[7141]: epoll_ctl(11, EPOLL_CTL_DEL, 128, 0x7fff7eb5812c) = 0

[6663]: recvmsg(128, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC}, 0) = 1
[7141]: recvmsg(128, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[15]}], msg_controllen=24, msg_flags=0}, 0) = 1



Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy: TLS handshake failed for service=smtp

Viktor Dukhovni
> On Mar 29, 2021, at 3:45 PM, Tomas Habarta <[hidden email]> wrote:
>
> 6663]: recvmsg(128, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC}, 0) = 1
> [7141]: recvmsg(128, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[15]}], msg_controllen=24, msg_flags=0}, 0) = 1

This is the crucial difference the control message with the forwarded
file descriptor is missing.  The SELinxu system is reporting MSG_CTRUNC
and a control length of 0.  The fine manpage says:

   MSG_CTRUNC
       indicates that some control data was discarded due to lack of
       space in the buffer for ancillary data.

But the issue is NOT lack of space, SELinux almost certainly censored
the descriptor passing.  See section 5.3.4 of:

   https://www.nsa.gov/Portals/70/documents/resources/everyone/digital-media-center/publications/research-papers/implementing-selinux-as-linux-security-module-report.pdf

Or https://bugzilla.redhat.com/show_bug.cgi?id=1326502

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy: TLS handshake failed for service=smtp

Tomas Habarta
On Mon, Mar 29, 2021 at 04:06:51PM -0400, Viktor Dukhovni wrote:

> > On Mar 29, 2021, at 3:45 PM, Tomas Habarta <[hidden email]> wrote:
> >
> > 6663]: recvmsg(128, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC}, 0) = 1
> > [7141]: recvmsg(128, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[15]}], msg_controllen=24, msg_flags=0}, 0) = 1
>
> This is the crucial difference the control message with the forwarded
> file descriptor is missing.  The SELinxu system is reporting MSG_CTRUNC
> and a control length of 0.  The fine manpage says:
>
>    MSG_CTRUNC
>        indicates that some control data was discarded due to lack of
>        space in the buffer for ancillary data.
>
> But the issue is NOT lack of space, SELinux almost certainly censored
> the descriptor passing.  See section 5.3.4 of:
>
>    https://www.nsa.gov/Portals/70/documents/resources/everyone/digital-media-center/publications/research-papers/implementing-selinux-as-linux-security-module-report.pdf
>
> Or https://bugzilla.redhat.com/show_bug.cgi?id=1326502
>
> --
> Viktor.
>

I see, that makes sense, thanks for the explanation and references, definitely something to read through. Hopefully I will find a systematic approach to a solution there...
Think it's time to explore what the policy status is in Fedora as it ships with Postfix > 3.4 (CentOS8 is currently at 3.3.1).

Tomas