Bug 375431

Summary: sshd denies logins due to SELinux denial
Product: [Fedora] Fedora Reporter: Ben Webb <ben>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 8CC: dwalsh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Current Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-16 14:05:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace-sshd.gz none

Description Ben Webb 2007-11-11 04:19:18 UTC
Description of problem:

Cannot login via ssh to F8 (i386 and x86_64) machines with password auth. The login proceeds 
normally, accepts the password, but then drops the connection. Client reports "Connection closed by 
aaa.bbb.ccc.ddd".  Server logs say:

Nov 10 20:03:18 xxx kernel: audit(1194753798.854:56): avc:  denied  { read write } for  pid=2553 
comm="sshd" path=2F535953563030303030303030202864656C6574656429 dev=tmpfs ino=65538 
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file
Nov 10 20:03:18 xxx kernel: sshd[2553]: segfault at ffffffffffffffff rip 00002aaaad32a8c0 rsp 
00007fff77580df8 error 6

Notably, ssh as the root user always succeeds. ssh with Kerberos (gssapi-with-mic) also succeeds. 
Disabling SELinux with 'setenforce 0' also "fixes" the problem.

May also be a mislabeled file somewhere, although the error message doesn't make it clear where this 
might be.

Version-Release number of selected component (if applicable):
openssh-server-4.7p1-2.fc8
selinux-policy-targeted-3.0.8-47.fc8

How reproducible:
Always.


Steps to Reproduce:
1. Discard Kerberos token on client (if applicable) with 'kdestroy'
2. ssh to affected F8 machine.
  
Actual results:
Client reports "Connection closed by ..."

Expected results:
Login shell on server.

Comment 1 Ben Webb 2007-11-11 06:04:30 UTC
An strace on the sshd process shows the crash of the child process:
...
2983  shmget(IPC_PRIVATE, 463, IPC_CREAT|0600) = 360453
2983  shmat(360453, 0, 0)               = -1 EACCES (Permission denied)
2983  --- SIGSEGV (Segmentation fault) @ 0 (0) ---

With SELinux disabled, the shmat suceeds and the process does not segfault.

Comment 2 Ben Webb 2007-11-12 06:38:08 UTC
A couple more data points:
1. A reboot and autorelabel did not change the symptoms at all.
2. The errors suggest (to me) mislabeling of /dev/shm, but it looks OK to me:
drwxrwxrwt  root root system_u:object_r:tmpfs_t        /dev/shm/


Comment 3 Tomas Mraz 2007-11-12 08:40:52 UTC
Could you attach bigger part of the strace (of course with non-valuable password
used). Also please try to create a backtrace with gdb with debuginfo packages
installed.

Comment 4 Ben Webb 2007-11-12 09:21:30 UTC
Created attachment 255031 [details]
strace-sshd.gz

This is a full strace - pid 2079 is the listener sshd process. I attached
strace to pid 2079 on the server, and then immediately tried to log in from the
client as 'testuser'. The strace ends shortly after the segfault of the child
process (pid 2904).

Notice that we do Kerberos auth against the SALILAB.ORG realm. (I created a
testuser principal for the purposes of this test.) If, however, the principal
is deleted and Unix password auth is used instead, sshd does not crash (this
presumably explains why root logins work, since we don't use Kerberos for
them).

I can't figure out right now how to attach gdb to the sshd process correctly (I
can attach to the pid of the listener process, but even with 'set
detach-on-fork off' this seems to prevent sshd from forking and accepting any
new client connections). Any suggestions?

Comment 5 Daniel Walsh 2007-11-12 21:52:11 UTC
Fixed in selinux-policy-3.0.8-53.fc8

Comment 6 Ben Webb 2007-11-16 00:10:30 UTC
Confirmed: selinux-policy-3.0.8-53.fc8 fixes this problem for me on both i386
and x86_64 systems.