Bug 231695 - LSPP: user unable to ssh to system with user/role/level context
Summary: LSPP: user unable to ssh to system with user/role/level context
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openssh   
(Show other bugs)
Version: 5.0
Hardware: ppc64
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Tomas Mraz
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 234654 RHEL5LSPPCertTracker
TreeView+ depends on / blocked
 
Reported: 2007-03-10 01:00 UTC by Loulwa Salem
Modified: 2018-10-19 22:47 UTC (History)
5 users (show)

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


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:0540 normal SHIPPED_LIVE Moderate: openssh security and bug fix update 2007-11-07 16:19:19 UTC

Description Loulwa Salem 2007-03-10 01:00:55 UTC
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 12:39:13 UTC
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 22:59:50 UTC
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-13 00:05:53 UTC
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-13 00:26:57 UTC
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 20:58:46 UTC
Reverting policy is not necessary only openssh*

Comment 6 Tomas Mraz 2007-03-19 13:03:32 UTC
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 13:42:47 UTC
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 14:36:38 UTC
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 17:50:16 UTC
QE ack for RHEL5.1.

Comment 10 Kylene J Hall 2007-03-19 23:42:38 UTC
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 07:32:33 UTC
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 17:07:01 UTC
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 18:10:46 UTC
(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 19:20:18 UTC
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 21:53:38 UTC
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 22:23:01 UTC
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 18:42:02 UTC
----- 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 07:11:59 UTC
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 15:32:38 UTC
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.