Bug 231695

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