Bug 411461 - selinux prevents ssh login with password
Summary: selinux prevents ssh login with password
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 8
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-05 03:20 UTC by Gus Wirth
Modified: 2007-12-10 19:31 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-12-10 19:31:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Gus Wirth 2007-12-05 03:20:34 UTC
Description of problem:

selinux prevents ssh login using a password.

Fault is caused by denying access to read /etc/shadow file.

From the /var/log/audit.log file:

type=USER_LOGIN msg=audit(1196819425.529:62): user pid=2816 uid=0 auid=500
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='acct="gus":
exe="/usr/sbin/sshd" (hostname=?, addr=192.168.1.200, terminal=sshd res=failed)'

Then from /var/log/messages:

Dec  4 17:34:07 falcon sshd[2714]: Server listening on 0.0.0.0 port 22.
Dec  4 17:50:30 falcon sshd[2816]: error: Could not get shadow information for gus
Dec  4 17:50:30 falcon sshd[2816]: Failed password for gus from 192.168.1.200
port 57568 ssh2

Changing system policy to permissive vs enforcing allows login using password.

Version-Release number of selected component (if applicable):

selinux-policy-3.0.8-62.fc8

How reproducible:

Steps to Reproduce:
1. attempt to login via ssh using a password to authenticate
  
Actual results:

ssh login is denied.

Expected results:

ssh login allowed.

Additional info:

Previous release was working.

Comment 1 Daniel Walsh 2007-12-05 15:46:17 UTC
Are you seeing any avc messages in /var/log/audit/audit.log?

Are you saying this was working in FC8 and just stopped when you upgraded to 62?

Comment 2 Gus Wirth 2007-12-05 16:51:07 UTC
I haven't seen any avc message. The only message I saw was the one posted above.

This was working correctly before the upgrade. After the upgrade, the only way I
could log in using ssh was to change the system policy from enforcing to
permissive. System reboot had no effect.


Comment 3 Gus Wirth 2007-12-05 18:47:40 UTC
Some more testing shows that if I run sshd in debug mode as root like this:

# /usr/sbin/sshd -e -ddd

I CAN connect when selinux is set to enforcing mode! So it looks like sshd is
being blocked only when it runs normally from its startup script.

Comment 4 Daniel Walsh 2007-12-05 21:39:01 UTC
When you login in permissive mode what is the context you are logging in with?

id -Z

Also what is the context that ssh is running with?



Comment 5 Gus Wirth 2007-12-05 23:06:03 UTC
With selinux enabled and logged in at the console, I get a security context of:
system_u:system_r:unconfined_t:s0-s0:c0.c1023

Switching to permissive mode and logging in via ssh:

[gus@falcon ~]$ ssh 192.168.1.200
gus.1.200's password:
Last login: Wed Dec  5 14:38:30 2007
[gus@falcon ~]$ id -Z
system_u:system_r:unconfined_t:s0-s0:c0.c1023

The ssh client normally runs on another machine without selinux. For the sshd
daemon I get:

[gus@falcon ~]$ ls -Z /usr/sbin/sshd
-rwxr-xr-x  root root system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd

This is when logged in with ssh and selinux in permissive mode:

[gus@falcon ~]$ ps -efZ|grep ssh
system_u:system_r:sshd_t:s0-s0:c0.c1023 root 1842  1  0 14:38 ?        00:00:00
/usr/sbin/sshd
system_u:system_r:unconfined_t:s0-s0:c0.c1023 gus 2688 2555  0 14:55 pts/1
00:00:00 ssh 192.168.1.200
system_u:system_r:sshd_t:s0-s0:c0.c1023 root 2689 1842  0 14:55 ?      00:00:00
sshd: gus [priv]
system_u:system_r:sshd_t:s0-s0:c0.c1023 gus 2691 2689  0 14:55 ?       00:00:00
sshd: gus@pts/2

The /etc/ssh/sshd_config file:

[gus@falcon ~]$ ls -Z /etc/ssh/sshd_config
-rw-------  root root system_u:object_r:etc_t:s0       /etc/ssh/sshd_config

The /etc/shadow file:

[gus@falcon ~]$ ls -Z /etc/shadow
-r--------  root root system_u:object_r:shadow_t:s0    /etc/shadow


Comment 6 Daniel Walsh 2007-12-06 20:18:40 UTC
Ok execute 

#semodule -DB

Attempt to login via ssh.

You should see avc messages in /var/log/audit/audit.log.


Comment 7 Gus Wirth 2007-12-06 22:03:11 UTC
Done. Now I get an AVC as follows from the audit.log:

type=AVC msg=audit(1196977802.577:184): avc:  denied  { read } for  pid=2619
comm="sshd" name="shadow" dev=sda1 ino=32346
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:shadow_t:s0 tclass=file


Comment 8 Daniel Walsh 2007-12-07 01:49:05 UTC
Are you using pam?  pam_unix should not be trying to read the shadow file
directly it should be using unix_chkpwd?

Comment 9 Gus Wirth 2007-12-07 03:09:14 UTC
Eureka! I checked my sshd_conf file and found that the UsePAM option was
commented out. I had copied over a sshd_config file from some other work I was
getting ready to do with the High Performance Networking (HPN) patch and it
didn't have the UsePAM option uncommented. That happened at about the same time
as the update that came in.

Thanks for your assistance and patience! It never would have occurred to me to
check PAM. 

For the lurkers:  By default, sshd does NOT use PAM, you have to tell it in the
sshd_config file. 


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