From: kindloaf@gmail.com (Hong) Date: Tue, 16 Sep 2008 14:19:07 -0400 Subject: [refpolicy] ssh issue with latest policy In-Reply-To: References: <20080911125025.GA5448@bobek.pm.i.cz> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com I shutdown the sshd and restart it, now I can connect without problem. (permissive mode). Thanks for the information! And I reboot the machine and switched to enforcing mode, the machine cannot boot normally. Looks like rcS doesn't work: exec: 7: /etc/init.d/rcS: Permission denied init: rcS main process (2335) terminated with status 2 init: rc-default main process (2337) terminated with status 1 And then the machine just hung there. I could not log in. ps: sorry for the delay. I had some deadline last week... Hong On Thu, Sep 11, 2008 at 5:01 PM, Justin Mattock wrote: > On Thu, Sep 11, 2008 at 5:50 AM, V?clav Ovs?k wrote: > > On Wed, Sep 10, 2008 at 12:32:31PM -0700, Justin Mattock wrote: > >> Hong, > >> I cant seem to locate the post you sent a few days ago > >> about logging into ssh. anyways I finally got around to logging into > >> my machines with both the latest kernel and refpolicy; > >> there was difficulty due to having /etc/host and /etc/sysctl.conf > >> variables in these files preventing me from logging in. > >> So with that in mind check and make sure those files > >> are cleared of anything that might cause an error. > >> As for the policy itself they were both in permissive mode > >> via boot param, so having /etc/selinux/config in enforcing > >> didnt cause an ubstruction for me. > >> hope this helps. > > > > May be. And Hong not replied yet if he did relabel the file system. :) > > > > I have tried to restart sshd with nonsense context to show the problem > > even with PERMISSIVE mode of SE Linux! > > > > sid:~# sestatus > > SELinux status: enabled > > SELinuxfs mount: /selinux > > Current mode: permissive > > Mode from config file: enforcing > > Policy version: 23 > > Policy from config file: default > > > > sid:~# runcon sysadm_u:sysadm_r:sysadm_t:s0 /etc/init.d/ssh restart > > > > sid:~# ps -H -Z -C sshd > > LABEL PID TTY TIME CMD > > sysadm_u:sysadm_r:sysadm_t:s0 1944 ? 00:00:00 sshd > > system_u:system_r:sshd_t:s0-s0:c0.c1023 1808 ? 00:00:00 sshd > > system_u:system_r:sshd_t:s0-s0:c0.c1023 1810 ? 00:00:00 sshd > > > > That is the new parent process sshd running with > sysadm_u:sysadm_r:sysadm_t:s0. > > > > zito at bobek:~$ ssh sid > > Read from remote host sid: Connection reset by peer > > Connection to sid closed. > > > > sid:~# tail -2 /var/log/syslog > > Sep 11 14:32:18 sid kernel: [ 649.880210] sshd[1954]: segfault at 2 ip > b7ad5cea sp bfc2b04c error 4 in libc-2.7.so[b7a60000+155000] > > Sep 11 14:32:18 sid kernel: [ 649.883080] type=1701 > audit(1221136338.451:27): auid=4294967295 uid=1000 gid=1000 ses=4294967295 > subj=sysadm_u:sysadm_r:sysadm_t:s0 pid=1954 comm="sshd" sig=11 > > > > > > This is mature for bug report on openssh. > > Conclusion: Running SE Linux in permissive mode can't prevent you from > > all SE Linux problems every time! (in most cases yes of course :) > > > > -- > > Zito > > > > appologize for the latency with getting back to you; > you might have the ssh version from sid, if so > do /etc/init.d/ssh stop and start if you notice [fail] then thats the > issue, > esspecially if people are booting up and not even manually starting the > daemon. > As for the policy and ssh I'm in the process of > having two machines in full enforcing mode, having the ability > to do a ssh transaction(need to configure some things); As well > as vncviewer, and shoutcast; all with ipsec. (AH and ESP) > right now I've been able to run all three applications on the machine > that is in full enforcement, but it seems im having issues with ipsec > and shoutcast. > on the server side. > I'll get back to you on this. > > -- > Justin P. Mattock > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20080916/4904aaa5/attachment.html