On Tue, Sep 16, 2008 at 11:19 AM, Hong <kindloaf@xxxxxxxxx> wrote: > 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 <justinmattock@xxxxxxxxx> > wrote: >> >> On Thu, Sep 11, 2008 at 5:50 AM, Václav Ovsík <vaclav.ovsik@xxxx> 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@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 > > Cool ssh works for you now. As for rc.d you can try and do: make enableaudit to see if there is some missing avc's, and also relabel the filesystem in case rc.d was labeled wrong -- Justin P. Mattock -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
