Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openssh
Version: 5.0
Hardware: ppc64
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Tomas Mraz
QA Contact: David Lawrence
URL:
Whiteboard:
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:
Clone Of:
Environment:
Last Closed: 2007-11-07 15:32:38 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System 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.