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.
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.
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/
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.
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?
Fixed in selinux-policy-3.0.8-53.fc8
Confirmed: selinux-policy-3.0.8-53.fc8 fixes this problem for me on both i386 and x86_64 systems.