Re: selinux hasn't been running for over a week
On Thursday 17 September 2009 09:39:48 pm Yuan Yijun wrote: What's happened in our rawhide boot sequence that cause selinux to not be running anymore? Selinux is not disabled in the grub.conf kernel line and sestatus shows its disabled. There is nothing in the system logs saying that there was a problem. I encountered this problem as well, but don't know why. It happens when I am trying different kernels among some recent builds (starting from 0.104 to 1.14). I guess there is a incompatible between older kernels and the policy; when you install a kernel while SELinux is disabled, it may cause future problems. Do you expect SELinux to be enabled automatically? Yes I do. I have not disabled selinux in any of the configuration. I usually enable SELinux by doing a relabel, then install the kernel again. relabeling is totally different than the system not having it enabled at all when its supposed to. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On Fri, 2009-09-18 at 07:34 -0400, Daniel J Walsh wrote: On 09/17/2009 09:39 PM, Yuan Yijun wrote: 2009/9/18 Steve Grubb sgr...@redhat.com: hi, What's happened in our rawhide boot sequence that cause selinux to not be running anymore? Selinux is not disabled in the grub.conf kernel line and sestatus shows its disabled. There is nothing in the system logs saying that there was a problem. I encountered this problem as well, but don't know why. It happens when I am trying different kernels among some recent builds (starting from 0.104 to 1.14). I guess there is a incompatible between older kernels and the policy; when you install a kernel while SELinux is disabled, it may cause future problems. Do you expect SELinux to be enabled automatically? I usually enable SELinux by doing a relabel, then install the kernel again. Hopefully this is just a problem of coordination between the old way of doing things and the new new. Dracut found a bug where it could not load_policy on separate /usr partitions because it needed to execute /usr/sbin/load_policy (obviously). I moved load_policy from /usr/sbin to /sbin. This caused some other apps problems because they were hard coded to look for /usr/sbin. Recently I fixed this by adding a symbolic link and fixing the libraries that blew up. Why can't dracut just directly invoke the libselinux interface (selinux_init_load_policy)? Then you don't have to care where the load_policy program lives. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On Fri, 2009-09-18 at 09:17 -0400, Daniel J Walsh wrote: On 09/18/2009 08:35 AM, Stephen Smalley wrote: On Fri, 2009-09-18 at 07:34 -0400, Daniel J Walsh wrote: On 09/17/2009 09:39 PM, Yuan Yijun wrote: 2009/9/18 Steve Grubb sgr...@redhat.com: hi, What's happened in our rawhide boot sequence that cause selinux to not be running anymore? Selinux is not disabled in the grub.conf kernel line and sestatus shows its disabled. There is nothing in the system logs saying that there was a problem. I encountered this problem as well, but don't know why. It happens when I am trying different kernels among some recent builds (starting from 0.104 to 1.14). I guess there is a incompatible between older kernels and the policy; when you install a kernel while SELinux is disabled, it may cause future problems. Do you expect SELinux to be enabled automatically? I usually enable SELinux by doing a relabel, then install the kernel again. Hopefully this is just a problem of coordination between the old way of doing things and the new new. Dracut found a bug where it could not load_policy on separate /usr partitions because it needed to execute /usr/sbin/load_policy (obviously). I moved load_policy from /usr/sbin to /sbin. This caused some other apps problems because they were hard coded to look for /usr/sbin. Recently I fixed this by adding a symbolic link and fixing the libraries that blew up. Why can't dracut just directly invoke the libselinux interface (selinux_init_load_policy)? Then you don't have to care where the load_policy program lives. The beauty of load_policy is that we don't end up having to suck the libsemanage and friends into the initrd. I think it is much saner then what we were doing in F11. Oh, I didn't realize that you had changed approaches. That makes Fedora more like Ubuntu's approach to handling initial policy load. FWIW, Debian is planning to patch upstart to load policy the way sysvinit used to do it. Then they don't require an initrd to perform the initial policy load. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On Fri, 2009-09-18 at 10:01 -0400, Steve Grubb wrote: On Friday 18 September 2009 09:54:12 am Daniel J Walsh wrote: If the kernel has SELinux and it is not in permissive mode, it should execute load_policy Yes in permissive mode load_policy will return 2 if it can not load policy. I guess dracut should also look in /etc/selinux/config to see if the SELINUX environment variable is not set to enforcing. What about interaction with the kernel command line? What the kernel was given is listed in /proc/cmdline. iow, if I boot with selinux=0 and the config says enabled, shouldn't the kernel command line take priority? That all gets taken care of inside of libselinux selinux_init_load_policy() function, which is what load_policy calls. You mean if the machine is in permissive mode, it should load_policy, but not crash. But it should log the reason so it can be debugged. Load_policy will exit with 0 on success or 2 on failure and SELinux in permissive mode. And if chroot fails, we need to handle it. This will probably crash anyways In the code I looked at, only if it returned 3... load_policy exits with 3 if the load policy failed and the system was supposed to be in enforcing mode (based on the combination of kernel command line arguments, which do take precedence, and the /etc/selinux/config setting). It exits with 2 if the load policy failed and the system was supposed to be permissive. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On 09/18/2009 10:01 AM, Steve Grubb wrote: On Friday 18 September 2009 09:54:12 am Daniel J Walsh wrote: If the kernel has SELinux and it is not in permissive mode, it should execute load_policy Yes in permissive mode load_policy will return 2 if it can not load policy. I guess dracut should also look in /etc/selinux/config to see if the SELINUX environment variable is not set to enforcing. What about interaction with the kernel command line? What the kernel was given is listed in /proc/cmdline. iow, if I boot with selinux=0 and the config says enabled, shouldn't the kernel command line take priority? Yes kernel command line wins. Second is /etc/selinux/config (SELINUX) line Execute the kernel command line to initialize the selinux and enforcing environment variables. cmdline options are (selinux=0 to disable SELinux) (enforcing=0 to put selinux in permissive mode) then dracut should execute . /etc/selinux/config if [ $selinux != 0 $enforcing != 0 $SELINUX == enforcing ]; then load_policy if $? != 0; ReportError() blow up elif [ $selinux != 0 ($enforcing == 0 || $SELINUX == permissive) ]; then load_policy if $? != 0; ReportError() # Continue no matter what elif [ $selinux == 0 || $enforcing == 0 || $SELINUX == disabled ]; then # Continue no matter what, although it would nice to tell the kernel to drop SELinux support elif Report_error() Blow Up endif You mean if the machine is in permissive mode, it should load_policy, but not crash. But it should log the reason so it can be debugged. Load_policy will exit with 0 on success or 2 on failure and SELinux in permissive mode. And if chroot fails, we need to handle it. This will probably crash anyways In the code I looked at, only if it returned 3... -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On 09/18/2009 10:05 AM, Stephen Smalley wrote: On Fri, 2009-09-18 at 10:01 -0400, Steve Grubb wrote: On Friday 18 September 2009 09:54:12 am Daniel J Walsh wrote: If the kernel has SELinux and it is not in permissive mode, it should execute load_policy Yes in permissive mode load_policy will return 2 if it can not load policy. I guess dracut should also look in /etc/selinux/config to see if the SELINUX environment variable is not set to enforcing. What about interaction with the kernel command line? What the kernel was given is listed in /proc/cmdline. iow, if I boot with selinux=0 and the config says enabled, shouldn't the kernel command line take priority? That all gets taken care of inside of libselinux selinux_init_load_policy() function, which is what load_policy calls. You mean if the machine is in permissive mode, it should load_policy, but not crash. But it should log the reason so it can be debugged. Load_policy will exit with 0 on success or 2 on failure and SELinux in permissive mode. And if chroot fails, we need to handle it. This will probably crash anyways In the code I looked at, only if it returned 3... load_policy exits with 3 if the load policy failed and the system was supposed to be in enforcing mode (based on the combination of kernel command line arguments, which do take precedence, and the /etc/selinux/config setting). It exits with 2 if the load policy failed and the system was supposed to be permissive. Right but what happens if load_policy is called with the wrong parameter? What happens if load_policy can not be called because of permission denied? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On Fri, 2009-09-18 at 10:16 -0400, Daniel J Walsh wrote: On 09/18/2009 10:05 AM, Stephen Smalley wrote: On Fri, 2009-09-18 at 10:01 -0400, Steve Grubb wrote: On Friday 18 September 2009 09:54:12 am Daniel J Walsh wrote: If the kernel has SELinux and it is not in permissive mode, it should execute load_policy Yes in permissive mode load_policy will return 2 if it can not load policy. I guess dracut should also look in /etc/selinux/config to see if the SELINUX environment variable is not set to enforcing. What about interaction with the kernel command line? What the kernel was given is listed in /proc/cmdline. iow, if I boot with selinux=0 and the config says enabled, shouldn't the kernel command line take priority? That all gets taken care of inside of libselinux selinux_init_load_policy() function, which is what load_policy calls. You mean if the machine is in permissive mode, it should load_policy, but not crash. But it should log the reason so it can be debugged. Load_policy will exit with 0 on success or 2 on failure and SELinux in permissive mode. And if chroot fails, we need to handle it. This will probably crash anyways In the code I looked at, only if it returned 3... load_policy exits with 3 if the load policy failed and the system was supposed to be in enforcing mode (based on the combination of kernel command line arguments, which do take precedence, and the /etc/selinux/config setting). It exits with 2 if the load policy failed and the system was supposed to be permissive. Right but what happens if load_policy is called with the wrong parameter? What happens if load_policy can not be called because of permission denied? I'm not entirely clear as to why you are asking, but: $ load_policy --foo load_policy: invalid option -- '-' usage: load_policy [-qi] $ echo $? 1 $ runcon system_u:system_r:httpd_t:s0 load_policy runcon: load_policy: Permission denied $ echo $? 126 Are you just saying that dracut needs to fail closed (i.e. halt the system) if the exit code is anything other than 0 (success) or 2 (failed but permissive)? -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On 09/18/2009 10:25 AM, Stephen Smalley wrote: On Fri, 2009-09-18 at 10:16 -0400, Daniel J Walsh wrote: On 09/18/2009 10:05 AM, Stephen Smalley wrote: On Fri, 2009-09-18 at 10:01 -0400, Steve Grubb wrote: On Friday 18 September 2009 09:54:12 am Daniel J Walsh wrote: If the kernel has SELinux and it is not in permissive mode, it should execute load_policy Yes in permissive mode load_policy will return 2 if it can not load policy. I guess dracut should also look in /etc/selinux/config to see if the SELINUX environment variable is not set to enforcing. What about interaction with the kernel command line? What the kernel was given is listed in /proc/cmdline. iow, if I boot with selinux=0 and the config says enabled, shouldn't the kernel command line take priority? That all gets taken care of inside of libselinux selinux_init_load_policy() function, which is what load_policy calls. You mean if the machine is in permissive mode, it should load_policy, but not crash. But it should log the reason so it can be debugged. Load_policy will exit with 0 on success or 2 on failure and SELinux in permissive mode. And if chroot fails, we need to handle it. This will probably crash anyways In the code I looked at, only if it returned 3... load_policy exits with 3 if the load policy failed and the system was supposed to be in enforcing mode (based on the combination of kernel command line arguments, which do take precedence, and the /etc/selinux/config setting). It exits with 2 if the load policy failed and the system was supposed to be permissive. Right but what happens if load_policy is called with the wrong parameter? What happens if load_policy can not be called because of permission denied? I'm not entirely clear as to why you are asking, but: $ load_policy --foo load_policy: invalid option -- '-' usage: load_policy [-qi] $ echo $? 1 $ runcon system_u:system_r:httpd_t:s0 load_policy runcon: load_policy: Permission denied $ echo $? 126 Are you just saying that dracut needs to fail closed (i.e. halt the system) if the exit code is anything other than 0 (success) or 2 (failed but permissive)? Well it is not that simple. If the kernel cmdline had selinux=0 or enforcing=0 or /etc/selinux/config had SELINUX=disabled or SELINUX=permissive then it should continue, otherwise the machine has to be assumed to be in enforcing mode, so if it can not load policy it is a system failure. I would figure this is what the MLS crowd would want. You configured the machine to run in enforcing mode and the system can not load policy for some reason, you need to crash. This is what the old patches did. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
selinux hasn't been running for over a week
hi, What's happened in our rawhide boot sequence that cause selinux to not be running anymore? Selinux is not disabled in the grub.conf kernel line and sestatus shows its disabled. There is nothing in the system logs saying that there was a problem. If selinux is not disabled and it does not become permissive or enforcing, it has to get logged and optionally shutdown the system. Aside from no logging, any ideas why selinux no longer works? Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
2009/9/18 Steve Grubb sgr...@redhat.com: hi, What's happened in our rawhide boot sequence that cause selinux to not be running anymore? Selinux is not disabled in the grub.conf kernel line and sestatus shows its disabled. There is nothing in the system logs saying that there was a problem. I encountered this problem as well, but don't know why. It happens when I am trying different kernels among some recent builds (starting from 0.104 to 1.14). I guess there is a incompatible between older kernels and the policy; when you install a kernel while SELinux is disabled, it may cause future problems. Do you expect SELinux to be enabled automatically? I usually enable SELinux by doing a relabel, then install the kernel again. -- bbbush ^_^ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
