On Tue, 17 Mar 2020, Dominick Grift wrote:
> > All right, so rather than try to change the programs, I added the
> > following TE rule:
> >
> > allow sshd_t unconfined_service_t:tcp_socket { getattr setopt };
> >
> > With that, sshd under tcpserver worked okay in permissive mode, with no
> > AVC notices in audit.log. But when I changed to enforcing mode, the
> > program failed for no apparent reason (and again, no AVC messages).
> > The remote system merely reported "Connection reset by peer". Any idea
> > what's wrong?
>
> You can run `semodule -DB` to make SELinux more verbose. (use `semodule
> -B` to make SELinux less verbose when youre done)
>
> My guess is that some socket accesses are silently blocked. Is a long
> story but the socket read and write accessed might be silently blocked
> because they are often false positives caused by leaked file
> descriptors.
>
> In this case the read write on tcp_socket would be legit and would need
> to be allowed.
>
> So if you do a `semodule -DB` then reproduce a login, then look for avc
> denials related to sshd_t, unconfined_service_t and tcp_sockets (my bet
> is on read and write) but eventually sshd obviously also needs to
> "accept" connections as well. In other words: "tcp_socket { getattr
> setopt }" is incomplete but the next access attempts (read/write) are
> silently blocked by policy and so without that it cannot do its job.
You hit the nail on the head. As it turns out, not only did sshd_t
need read/write access to the tcp_socket, so did sshd_net_t. I have no
idea what that type is for, but when I added the permission the program
worked.
Thanks for your help.
Alan Stern
