Bug 1678695

Summary: Do not fallback to sshd_net_t if /etc/selinux/POLICYTYPE/contexts/openssh_contexts doesn't exist
Product: [Fedora] Fedora Reporter: Petr Lautrbach <plautrba>
Component: opensshAssignee: Jakub Jelen <jjelen>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dac.override, dwalsh, jfch, jjelen, lkundrak, mattias.ellert, plautrba, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openssh-7.9p1-5.fc29 openssh-7.9p1-5.fc30 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-25 06:05:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Petr Lautrbach 2019-02-19 12:10:07 UTC
Description of problem:

sshd changes SELinux type of preauth privsep processes to the value set in /etc/selinux/POLICYTYPE/contexts/openssh_contexts and if this file doesn't exists, it uses hardcoded "sshd_net_t". While "sshd_net_t" is defined in targeted policy, users might want to use their own policies where "sshd_net_t" is not defined and they would get just a debug message.

Given that selinux-policy-targeted ships openssh_contexts, openssh doesn't need to hardcode sshd_net_t and simply doesn't try to change the type if the file doesn't exist.

See also https://lore.kernel.org/selinux/87d0np8tfw.fsf@gmail.com/

Comment 1 Jakub Jelen 2019-03-11 12:14:53 UTC
Lets summarize what is the expected behavior:

 * In default configuration, there should be no change in behavior (the file /etc/selinux/POLICYTYPE/contexts/openssh_contexts exists, is readable and contains "privsep_preauth=sshd_net_t"
 * If the file is not there, not readable or does not contain the privsep_preauth= option, we should not need to do anything (no change to hardcoded context). Maybe just a debug message what went wrong when accessing the file
 * If the file is there, but contains invalid context, we should write some log message (maybe even fatal?).

I will fix it in Fedora. Do we have some requirement to fix it also in RHEL8?

Comment 2 Jakub Jelen 2019-03-11 12:48:41 UTC
Proposed patch:

https://src.fedoraproject.org/fork/jjelen/rpms/openssh/c/447476eedb6099b397eab17f54fd6868b70db762

plautrba review=?

If there is invalid context specified in the file, the following is printed in the log (with logit()):

sshd[31674]: ssh_selinux_change_context: setcon system_u:system_r:sshd_net_ta:s0-s0:c0.c1023 from system_u:system_r:sshd_t:s0-s0:c0.c1023 failed with Invalid argument [preauth]

Additionally, few more log messages were added where it can fail during reading the selinux context files.

Comment 3 Petr Lautrbach 2019-03-12 14:03:23 UTC
It looks like file_context file descriptor is left open when stat() test fails.

The "SELinux context file needs to be owned by root" could be logged with a higher level as it's a configuration error. ssh_selinux_change_context() uses logid() when setcon() fails.

Comment 4 Jakub Jelen 2019-03-12 14:30:16 UTC
Thank you. I will fix the issues and build the package soon.

Comment 5 dac.override 2019-03-21 11:39:45 UTC
7.9p1-5 fixes it for me. Thanks

Comment 6 dac.override 2019-03-21 12:03:03 UTC
Would ofcourse be nice to have this in RHEL8.

By the way do you recall our conversation on #fedora-devel about an observation i made where openssh on RHEL7 behaves differently than openssh on Fedora WRT to spawning the shell when you log in? At that time you did confirm that there were difference in that part of the code. You also said that the Fedora code was probably doing the right thing compared to what the RHEL7 code was doing.

I really hope that openssh in RHEL8 will behave the same as openssh in Fedora in this regards.

Comment 7 Fedora Update System 2019-03-21 12:55:10 UTC
openssh-7.9p1-5.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-5f75a8e7b5

Comment 8 Jakub Jelen 2019-03-21 13:08:35 UTC
Thank you for verifying that it worked for you.

Comment 9 Fedora Update System 2019-03-21 13:18:57 UTC
openssh-7.9p1-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c3ff0f7530

Comment 10 Fedora Update System 2019-03-21 19:12:49 UTC
openssh-7.9p1-5.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-5f75a8e7b5

Comment 11 Fedora Update System 2019-03-21 21:19:14 UTC
openssh-7.9p1-5.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c3ff0f7530

Comment 12 Fedora Update System 2019-03-25 06:05:33 UTC
openssh-7.9p1-5.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2019-03-29 19:19:13 UTC
openssh-7.9p1-5.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.