From: kindloaf@gmail.com (Hong) Date: Tue, 16 Sep 2008 15:19:29 -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 Do you mean "make enableaudit" under the refpolicy source directory? I did this and the output is as follows: .../refpolicy-0.0.20071214$ sudo make enableaudit cat: /selinux/policyvers: No such file or directory Removing dontaudit rules from policy.conf egrep -v dontaudit policy.conf > tmp/policy.audit mv tmp/policy.audit policy.conf And I "sudo make relabel" under the refpolicy source directory to relabel the file system. (I already relabel the file system before). And after reboot, the machine still cannot boot. I found following entries in /var/log/syslog after another reboot with kernel option enforcing=0: Sep 16 15:07:27 hostname init: tty4 main process (4000) killed by TERM signal Sep 16 15:07:27 hostname init: tty5 main process (4001) killed by TERM signal Sep 16 15:07:27 hostname init: tty2 main process (4006) killed by TERM signal Sep 16 15:07:27 hostname init: tty3 main process (4008) killed by TERM signal Sep 16 15:07:27 hostname init: tty6 main process (4012) killed by TERM signal Sep 16 15:07:27 hostname init: tty1 main process (4314) killed by TERM signal Sep 16 15:07:27 hostname restorecond: terminated Sep 16 15:07:29 hostname postfix/master[4214]: terminating on signal 15 Sep 16 15:07:31 hostname kernel: [ 3579.730352] ip6_tables: (C) 2000-2006 Netfilter Core Sep 16 15:07:31 hostname exiting on signal 15 There is no entry in /var/log/messages for the unsuccessful reboot. Does it show any clue of the problem? Hong On Tue, Sep 16, 2008 at 2:38 PM, Justin Mattock wrote: > On Tue, Sep 16, 2008 at 11:19 AM, Hong 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 > > > 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 > > > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20080916/5a81d59e/attachment-0001.html