Re: [refpolicy] ssh issue with latest policy

[Hong <kindloaf@xxxxxxxxx>]

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 <justinmattock@xxxxxxxxx> wrote:

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