Bug 375431 - sshd denies logins due to SELinux denial
sshd denies logins due to SELinux denial
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-10 23:19 EST by Ben Webb
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-16 09:05:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace-sshd.gz (18.12 KB, application/x-gzip)
2007-11-12 04:21 EST, Ben Webb
no flags Details

  None (edit)
Description Ben Webb 2007-11-10 23:19:18 EST
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):

How reproducible:

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 01:04:30 EST
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 01:38:08 EST
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 03:40:52 EST
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
Comment 4 Ben Webb 2007-11-12 04:21:30 EST
Created attachment 255031 [details]

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

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 16:52:11 EST
Fixed in selinux-policy-3.0.8-53.fc8
Comment 6 Ben Webb 2007-11-15 19:10:30 EST
Confirmed: selinux-policy-3.0.8-53.fc8 fixes this problem for me on both i386
and x86_64 systems.

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