Hello. Thank you for filling the bug report. The bugzilla is not a support tool so to make sure the issue will get addressed as soon as possible, please contact your Red Hat support.


From missing information, can you identify when it was working last time? Does downgrade of OpenSSH package help? Does downgrade of SELinux-related packages help? Can it be related to PAM?

The DEBUG3 logs appearing in journal:

sshd[2929]: debug1: SELinux support enabled
sshd[2929]: debug3: sshd_selinux_setup_variables: setting execution context
sshd[2929]: debug1: PAM: establishing credentials
sshd[2929]: debug3: PAM: opening session
sshd[2929]: pam_selinux(sshd:session): Not a valid security context user_u:user_r:user_t:s0-s0:c0.c1023   <---- first error makes the pam failing?
sshd[2929]: pam_selinux(sshd:session): Unable to get valid context for test
sshd[2929]: debug3: PAM: sshpam_store_conv called with 1 messages
systemd[1]: Created slice user-1000.slice.
systemd[1]: Starting user-1000.slice.
systemd[1]: Started Session 9 of user test.
systemd-logind[621]: New session 9 of user test.
systemd[1]: Starting Session 9 of user test.
sshd[2929]: pam_unix(sshd:session): session opened for user test by (uid=0)
sshd[2929]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session   <---- consequence of the above
sshd[2929]: User child is on pid 2934
[...]
sshd[2929]: debug1: SELinux support enabled
sshd[2929]: debug3: ssh_selinux_setup_pty: setting TTY context on /dev/pts/2
sshd[2929]: error: ssh_selinux_setup_pty: security_compute_relabel: Invalid argument     <---- probably related to the first error -- PAM didn't set u proper execution context?
sshd[2929]: debug3: ssh_selinux_setup_pty: done
sshd[2929]: debug3: mm_request_send entering: type 29
sshd[2929]: debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 5
[...]
sshd[2935]: debug1: Setting controlling tty using TIOCSCTTY.
sshd[2935]: debug3: mm_request_send entering: type 124
sshd[2935]: debug3: PAM session not opened, exiting   <---- the fatal error finally taking the session down
sshd[2934]: debug2: notify_done: reading
sshd[2934]: debug1: Received SIGCHLD.


The most interesting is probably:

sshd[2929]: pam_selinux(sshd:session): Not a valid security context user_u:user_r:user_t:s0-s0:c0.c1023

can this be somehow related to the SELinux changes in recent RHEL release? Why does it behave different when started from socket than from service? The privileged sshd process is running with the correct SELinux labels:

    system_u:system_r:sshd_t:s0-s0:c0.c1023 3137 ? Ss     0:00 sshd: test [priv]

I can reproduce the same with both RHEL7.3, Fedora 25 at the moment.

This behavior comes from Common Criteria standard which requires ssh sessions to run at the level corresponding to the label of the network data and which is applied only when sshd is run with -i what is the case for socket activation.

For this particular case, the network data level is s0-s0:c0.c1023 and sshd tries to enforce the same level for user_t. user_t is not allowed to run with this level therefore pam_selinux reports invalid security context.

I guess that pam_selinux could be enhanced to handle correctly these cases. E.g. if a level which comes from a process is invalid, it can use a default level but only if the default level is allowed in the level from process.


Given that user types are not constrained in targeted policy possible workaround would be to set s0 level for sshd processes. 

# cat > /etc/systemd/system/sshd\@.service.d/s0-level.conf <<EOF
[Service]
SELinuxContext=system_u:system_r:sshd_t:s0
EOF

This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.