Description of problem: When a user tries to ssh into a system with the user/role/level context syntax, it is denied access Version-Release number of selected component (if applicable): selinux-policy-2.4.6-42.el5 2.6.18-8.el5.lspp.67 mcstrans-0.2.3-1.el5 How reproducible: Always Steps to Reproduce: 1. Create or use a user already on the system that is allowed to log in as sysadm_r at level s0-s15:c0.c1023 2. attempt to login (ssh -l user/sysadm_r/s0-s15:c0.c1023 localhost) Actual results: Read from remote host localhost: Connection reset by peer Connection to localhost closed. Expected results: ssh should succeed and user should be able to log in Additional info: in /var/log/messages I get the following: Mar 9 14:50:15 joy-hv4 sshd[16038]: Accepted keyboard-interactive/pam for ealuser from 127.0.0.1 port 42775 ssh2 Mar 9 14:50:15 joy-hv4 sshd[16038]: error: deny MLS level s0-s15:c0.c1023 (user range s0-s15:c0.c1023) Mar 9 14:50:15 joy-hv4 sshd[16038]: error: Failed to get default security context for ealuser. Mar 9 14:50:15 joy-hv4 sshd[16038]: fatal: SELinux failure. Aborting connection. in /var/log/audit/audit.log I get: type=USER_ROLE_CHANGE msg=audit(1173473415.924:939): user pid=16038 uid=0 auid=502 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='sshd: default- context=staff_u:staff_r:staff_t:s0-s15:c0.c1023 selected- context=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=? res=failed)' type=USER_ERR msg=audit(1173473415.933:940): user pid=16038 uid=0 auid=502 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: bad_ident acct=? : exe="/usr/sbin/sshd" (hostname=localhost.localdomain, addr=127.0.0.1, terminal=ssh res=failed)' Note: I already have ssh_sysadm_login boolean turned on Additional info about my user roles and levels (ealuser) Here is the relevant semanage user -l output SELinux User Prefix MCS Level MCS Range SELinux Roles staff_u staff SystemLow SystemLow-SystemHigh sysadm_r staff_r secadm_r auditadm_r and the semanage login -l output Login Name SELinux User MLS/MCS Range ealuser staff_u SystemLow-SystemHigh
The problem here is that you have not updated /etc/selinux/mls/contexts/default_type and /etc/selinux/mls/contexts/default_contexts You need to update these files when you add new user roles/types. This should be release noted and hopefully we will have a better solution after this week.
If I was adding or creating new roles/users on the system that would make sense to update the files accordingly. However, the problem I am seeing is when trying to log in with sysadm_r, which is a role defined on the system by default. I don't think we need to make additions to the files you mentioned. We never did before either .. certainly not for sysadm_r, so my guess is that something changed in the latest policy Note: Since opening this bug, we have seen this problem on every system that has been updated with the latest packages from the repo.
I am not sure this is a policy bug but rather and openssh bug. To work around the problem I first tried downleveling my policy to the previously known working version lspp.38, the problem persisted after a reboot (resetting ssh_sysadm_login) etc. I then downleveled the openssh packages to 4.3p2-17.el5 and restarted sshd. I was the able to login as before with username/role/level
Update: We reverted to policy .38 and openssh5.3-p2.17 on one of our systems and that works fine, we are able to log in as sysadm_r with a level selection. I also increased severity to high. This is blocking our tests.
Reverting policy is not necessary only openssh*
With the openssh-4.3p2-18.el5 - could you please try username//level and username/role variants of login and report which work and which don't. Also can you please dump here the 'ausearch -m USER_ROLE_CHANGE' messages generated by the login attempts?
ssh -l ealuser//s5 localhost works fine, I get a context as "staff_u:staff_r:staff_t:s5 ssh -l ealuser/sysadm_r/ localhost Does not work, I get "Connection to localhost closed" The "ausearch -m USER_ROLE_CHANGE" output: time->Mon Mar 19 04:07:51 2007 type=USER_ROLE_CHANGE msg=audit(1174295271.970:1699): user pid=12800 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='sshd: default-context=staff_u:staff_r:staff_t:s0-s15:c0.c1023 selected- context=staff_u:staff_r:staff_t:s5: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=? res=success)' ---- time->Mon Mar 19 04:12:15 2007 type=USER_ROLE_CHANGE msg=audit(1174295535.714:1734): user pid=12839 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='sshd: default-context=staff_u:staff_r:staff_t:s0-s15:c0.c1023 selected- context=staff_u:sysadm_r:sysadm_t:s15: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=? res=success)' I see the following in /var/log/messages Mar 19 04:12:15 joy-hv4 sshd[12839]: Accepted keyboard-interactive/pam for ealuser from 127.0.0.1 port 46539 ssh2 Mar 19 04:12:16 joy-hv4 sshd[12839]: error: setfilecon(/dev/pts/1, staff_u:object_r:sysadm_devpts_t) failed: Permission denied
I also tried ssh -l ealuser/sysadm_r/s5 localhost Does not work, I get .. Read from remote host localhost: Connection reset by peer Connection to localhost closed output from "ausearch -m USER_ROLE_CHANGE" ... time->Mon Mar 19 05:30:17 2007 type=USER_ROLE_CHANGE msg=audit(1174300217.728:369): user pid=2028 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='sshd: default-context=staff_u:staff_r:staff_t:s0-s15:c0.c1023 selected- context=staff_u:sysadm_r:sysadm_t:s5: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=? res=failed)' output from /var/log/messages .. Mar 19 05:30:17 joy-hv4 sshd[2028]: Accepted keyboard-interactive/pam for ealuser from 127.0.0.1 port 41238 ssh2 Mar 19 05:30:17 joy-hv4 sshd[2028]: error: deny MLS level s5 (user range s0- s15:c0.c1023) Mar 19 05:30:17 joy-hv4 sshd[2028]: error: Failed to get default security context for ealuser. Mar 19 05:30:17 joy-hv4 sshd[2028]: fatal: SELinux failure. Aborting connection.
QE ack for RHEL5.1.
The orginial issue of this not working: ssh -l user/sysadm_r/s0-s15:c0.c1023 localhost is fixed with the openssh-4.3p2-20. However, the following now (still?) does not work: ssh testuser/user_r/s3:c4.c5-s5:c4.c5@localhost ---- time->Mon Mar 19 12:11:20 2007 type=USER_ROLE_CHANGE msg=audit(1174324280.447:751): user pid=4048 uid=0 auid=503 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='sshd: default-context=testuser_u:user_r:user_t:s0-s15:c0.c1023 selected-context=testuser_u:user_r:user_t:s3:c4.c5-s5:c4.c5: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=? res=failed)'
You have to use s3:c4,c5-s5:c4,c5 in this case because the categories are next to each other.
This seems like a usability issue. When 1-3 is a valid range but 1-2 is not (1-2 has to be represented as a list as in 1,2) that is confusing. I understand that internally this has to be changed for consistency but it seems the user should be able to enter it as they see fit. This worked in openssh-4.3p2-17.
(In reply to comment #11) > You have to use s3:c4,c5-s5:c4,c5 in this case because the categories are next > to each other. > Tomas, was this change been applied to all programs who accept contexts? (read: was a mcstransd change or just a single openssh change?) Would this mean that the same rule applies for mounting with contexts, newrole, semanage, etc? I am with Kylene that this might be an usability issue (besides being an interface also). Do you know why has it changed from the previous behavior?
It's caused by fix for bug 229278 in openssh. But I have some idea how to fix this unintended side effect.
Based on comment #14, is this side effect behavior regarding the usage of category ranges going to be fixed?
The fix didn't work as I expected so I'm afraid that not for now. Perhaps it could be fixed in mcstrans. One more thing about the comment #12 - the problem isn't in level ranges, just in category ranges when dot is used with categories which are next to each other.
----- Additional Comments From klausk.com 2007-08-03 13:14 EDT ------- Bug still present in RHEL5.1-beta: [root/sysadm_r/SystemLow@magnetar ~]# ssh testuser/user_r/s3:c4,c5-s5:c4,c5@localhost Password: Last login: Fri Aug 3 12:13:40 2007 from localhost.localdomain [testuser/user_r/s3:c4,c5@magnetar ~]$ logout Connection to localhost closed. [root/sysadm_r/SystemLow@magnetar ~]# ssh testuser/user_r/s3:c4.c5-s5:c4.c5@localhost Password: Read from remote host localhost: Connection reset by peer Connection to localhost closed. [root/sysadm_r/SystemLow@magnetar ~]# audit output: type=USER_AUTH msg=audit(1186161308.676:514): user pid=7681 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: authentication acct="testuser" : exe="/usr/sbin/sshd" (hostname=localhost.localdomain, addr=127.0.0.1, terminal=ssh res=success)' type=USER_ACCT msg=audit(1186161308.687:515): user pid=7681 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: accounting acct="testuser" : exe="/usr/sbin/sshd" (hostname=localhost.localdomain, addr=127.0.0.1, terminal=ssh res=success)' type=USER_ROLE_CHANGE msg=audit(1186161308.703:516): user pid=7677 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='sshd: default-context=testuser_u:user_r:user_t:s0-s15:c0.c1023 selected-context=testuser_u:user_r:user_t:s3:c4.c5-s5:c4.c5: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=? res=failed)' type=USER_ERR msg=audit(1186161308.704:517): user pid=7677 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: bad_ident acct="?" : exe="/usr/sbin/sshd" (hostname=localhost.localdomain, addr=127.0.0.1, terminal=ssh res=failed)' This event sent from IssueTracker by jkachuck issue 115886
This particular issue - having to use c1,c2 instead of c1.c2 will not be fixed in RHEL-5.1. You can open a new bug report for this one as this bug deals with more general problem which was fixed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0540.html