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.
--
Justin P. Mattock
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
On Thu, Sep 11, 2008 at 5:50 AM, V?clav Ovs?k <[email protected]> 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
On Thu, September 11, 2008 14:50, V?clav Ovs?k wrote:
> Conclusion: Running SE Linux in permissive mode can't prevent you from
> all SE Linux problems every time! (in most cases yes of course :)
Another example of that is that dbus seems to do SELinux permission checks
even after permissive mode is enabled.
--
David H?rdeman
On Thu, Sep 11, 2008 at 02:01:08PM -0700, Justin Mattock wrote:
>...
> 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
I just reported the bug in sshd
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498684
This is upstream OpenSSH problem too.
On Fri, Sep 12, 2008 at 10:09:32AM +0200, David H?rdeman wrote:
> On Thu, September 11, 2008 14:50, V?clav Ovs?k wrote:
> > Conclusion: Running SE Linux in permissive mode can't prevent you from
> > all SE Linux problems every time! (in most cases yes of course :)
>
> Another example of that is that dbus seems to do SELinux permission checks
> even after permissive mode is enabled.
>
> --
> David H?rdeman
It should be reported if it is true, IMO.
Regards
--
Zito
On Fri, Sep 12, 2008 at 3:25 AM, V?clav Ovs?k <[email protected]> wrote:
> On Thu, Sep 11, 2008 at 02:01:08PM -0700, Justin Mattock wrote:
>>...
>> 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
>
> I just reported the bug in sshd
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498684
> This is upstream OpenSSH problem too.
>
> On Fri, Sep 12, 2008 at 10:09:32AM +0200, David H?rdeman wrote:
>> On Thu, September 11, 2008 14:50, V?clav Ovs?k wrote:
>> > Conclusion: Running SE Linux in permissive mode can't prevent you from
>> > all SE Linux problems every time! (in most cases yes of course :)
>>
>> Another example of that is that dbus seems to do SELinux permission checks
>> even after permissive mode is enabled.
>>
>> --
>> David H?rdeman
>
> It should be reported if it is true, IMO.
>
> Regards
> --
> Zito
>
Cool; I ended up downgrading to
a random pick of ssh_4.3p2-9etch2_all.deb
works good from here.
Just make sure you start in sysadm_r
role or you won't be able to do much to the other system while in enforcement
mode.(made the mistake of using ssh in user_r role.)
regards;
--
Justin P. Mattock
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 <[email protected]>wrote:
> On Thu, Sep 11, 2008 at 5:50 AM, V?clav Ovs?k <[email protected]> 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
On Tue, Sep 16, 2008 at 11:19 AM, Hong <[email protected]> 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 <[email protected]>
> wrote:
>>
>> On Thu, Sep 11, 2008 at 5:50 AM, V?clav Ovs?k <[email protected]> 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
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 <[email protected]>wrote:
> On Tue, Sep 16, 2008 at 11:19 AM, Hong <[email protected]> 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 <[email protected]
> >
> > wrote:
> >>
> >> On Thu, Sep 11, 2008 at 5:50 AM, V?clav Ovs?k <[email protected]>
> 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
On Tue, Sep 16, 2008 at 12:19 PM, Hong <[email protected]> wrote:
> 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 <[email protected]>
> wrote:
>>
>> On Tue, Sep 16, 2008 at 11:19 AM, Hong <[email protected]> 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
>> > <[email protected]>
>> > wrote:
>> >>
>> >> On Thu, Sep 11, 2008 at 5:50 AM, V?clav Ovs?k <[email protected]>
>> >> 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
>
>
Hmm, this is interesting, depending on what system you're using, you might
be facing somthing similar to what I was facing a few months ago with
powersaved i.g.
after allowing this daemon to move freely withing the policy,
I still was unable to set the power levels, or change from ondemand
module to the
powersave module with cpufrequencies(no avc's at all).
a simple downgrade resolvedthe issue(the main issue I think was
liblazy or one of the libraries);
Something similar to what you are experiencingwere the policy and the
daemon some how can't
communicate, to create an avc's, so you can go about you're way. If
you can depending on what
daemon is denied, try setting up you're network very early in the boot process
either in /etc/init.d/alsa-tools or acpid(somwhere before you receive
the permissions
denied message), then onceyou receive the freeze or whatever, use
another machine to ssh
into the frozen machine to grab dmesg and other
logs, so you have a better idea with what is happening.
I have this in my /etc/rc.local (for instances like this);
(change router to no WEP or WPA);
iwconfig ath0 essid "***"
ifconfig ath0 up
dhclient
/etc/init.d/ssh start
then use another machine to gather info on the freeze.
--
Justin P. Mattock