This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 231695 - LSPP: user unable to ssh to system with user/role/level context
LSPP: user unable to ssh to system with user/role/level context
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openssh (Show other bugs)
5.0
ppc64 Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
David Lawrence
:
Depends On:
Blocks: 234654 RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-03-09 20:00 EST by Loulwa Salem
Modified: 2010-10-22 09:38 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHSA-2007-0540
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 10:32:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Loulwa Salem 2007-03-09 20:00:55 EST
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
Comment 1 Daniel Walsh 2007-03-12 08:39:13 EDT
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.
Comment 2 Loulwa Salem 2007-03-12 18:59:50 EDT
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.
Comment 3 Kylene J Hall 2007-03-12 20:05:53 EDT
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
Comment 4 Loulwa Salem 2007-03-12 20:26:57 EDT
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.
Comment 5 Kylene J Hall 2007-03-14 16:58:46 EDT
Reverting policy is not necessary only openssh*
Comment 6 Tomas Mraz 2007-03-19 09:03:32 EDT
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?
Comment 7 Loulwa Salem 2007-03-19 09:42:47 EDT
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
Comment 8 Loulwa Salem 2007-03-19 10:36:38 EDT
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.
Comment 9 Jay Turner 2007-03-19 13:50:16 EDT
QE ack for RHEL5.1.
Comment 10 Kylene J Hall 2007-03-19 19:42:38 EDT
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)'
Comment 11 Tomas Mraz 2007-03-20 03:32:33 EDT
You have to use s3:c4,c5-s5:c4,c5 in this case because the categories are next
to each other.
Comment 12 Kylene J Hall 2007-03-20 13:07:01 EDT
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.
Comment 13 Klaus Heinrich Kiwi 2007-03-20 14:10:46 EDT
(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?
Comment 14 Tomas Mraz 2007-03-20 15:20:18 EDT
It's caused by fix for bug 229278 in openssh. But I have some idea how to fix
this unintended side effect.
Comment 15 Loulwa Salem 2007-04-03 17:53:38 EDT
Based on comment #14, is this side effect behavior regarding the usage of 
category ranges going to be fixed?
Comment 16 Tomas Mraz 2007-04-03 18:23:01 EDT
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.
Comment 19 Issue Tracker 2007-08-03 14:42:02 EDT
----- Additional Comments From klausk@br.ibm.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
Comment 20 Tomas Mraz 2007-08-06 03:11:59 EDT
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.
Comment 21 errata-xmlrpc 2007-11-07 10:32:38 EST
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

Note You need to log in before you can comment on or make changes to this bug.