Bug#929063: SELinux integration in sysVinit
[ Sorry, if I messed quotation. It is complex ] [2019-05-24 21:00] Jason Zaman > > > There is currently some discussion at [0] about SELinux > > > integration in sysVinit and the fact that somebody wants to > > > delegate the loading of the policy to an other binary than PID1. > > > > > > Has somebody a remark or an objection to that proposal? > > > > I object too. There is a *huge* change in functionality. Originally if > > you boot with SELinux enforcing, there are only two things that can > > happen. Either you end up with the policy loaded or the machine halts. > > > > In the new patch, an attacker can just chmod -x /sbin/selinux-check then > > next boot there will be no selinux enabled. > > > > if (access(SELINUX_CHECK, X_OK) != 0) fails, the machine will continue > > to boot without SELinux enabled. There is no difference between a user > > without /sbin/selinux-check on purpose and an attacker just chmod -x'd > > the tool. > > > > SELinux does not protect /sbin anywhere near as much as /etc/selinux > > (and doing that would probably be impossible). You'd need to check if > > selinux is enabled and enforcing before skipping the loading ... which > > is done by calling is_selinux_enabled() which needs linking to > > libselinux. The important part of the original design is not > > selinux_init_load_policy(), its is_selinux_enabled(). How does it come that attacker can just "chmod -x /sbin/selinux-check"? Aren't there supposed to be SELinux rule, preventing attacker from doing this, even if he cracked root process? Okay, this patch should be accompanied with patch to src:refpolicy, correct? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: SELinux integration in sysVinit
[ Sorry, if I messed quotation. It is complex ] [2019-05-24 21:00] Jason Zaman > > > There is currently some discussion at [0] about SELinux > > > integration in sysVinit and the fact that somebody wants to > > > delegate the loading of the policy to an other binary than PID1. > > > > > > Has somebody a remark or an objection to that proposal? > > > > I object too. There is a *huge* change in functionality. Originally if > > you boot with SELinux enforcing, there are only two things that can > > happen. Either you end up with the policy loaded or the machine halts. > > > > In the new patch, an attacker can just chmod -x /sbin/selinux-check then > > next boot there will be no selinux enabled. > > > > if (access(SELINUX_CHECK, X_OK) != 0) fails, the machine will continue > > to boot without SELinux enabled. There is no difference between a user > > without /sbin/selinux-check on purpose and an attacker just chmod -x'd > > the tool. > > > > SELinux does not protect /sbin anywhere near as much as /etc/selinux > > (and doing that would probably be impossible). You'd need to check if > > selinux is enabled and enforcing before skipping the loading ... which > > is done by calling is_selinux_enabled() which needs linking to > > libselinux. The important part of the original design is not > > selinux_init_load_policy(), its is_selinux_enabled(). How does it come that attacker can just "chmod -x /sbin/selinux-check"? Aren't there supposed to be SELinux rule, preventing attacker from doing this, even if he cracked root process? Okay, this patch should be accompanied with patch to src:refpolicy, correct? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: SELinux integration in sysVinit
[ Sorry, if I messed quotation. It is complex ] [2019-05-24 21:00] Jason Zaman > > > There is currently some discussion at [0] about SELinux > > > integration in sysVinit and the fact that somebody wants to > > > delegate the loading of the policy to an other binary than PID1. > > > > > > Has somebody a remark or an objection to that proposal? > > > > I object too. There is a *huge* change in functionality. Originally if > > you boot with SELinux enforcing, there are only two things that can > > happen. Either you end up with the policy loaded or the machine halts. > > > > In the new patch, an attacker can just chmod -x /sbin/selinux-check then > > next boot there will be no selinux enabled. > > > > if (access(SELINUX_CHECK, X_OK) != 0) fails, the machine will continue > > to boot without SELinux enabled. There is no difference between a user > > without /sbin/selinux-check on purpose and an attacker just chmod -x'd > > the tool. > > > > SELinux does not protect /sbin anywhere near as much as /etc/selinux > > (and doing that would probably be impossible). You'd need to check if > > selinux is enabled and enforcing before skipping the loading ... which > > is done by calling is_selinux_enabled() which needs linking to > > libselinux. The important part of the original design is not > > selinux_init_load_policy(), its is_selinux_enabled(). How does it come that attacker can just "chmod -x /sbin/selinux-check"? Aren't there supposed to be SELinux rule, preventing attacker from doing this, even if he cracked root process? Okay, this patch should be accompanied with patch to src:refpolicy, correct? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: SELinux integration in sysVinit
On 5/24/19 9:00 AM, Jason Zaman wrote: Bigon asked me to forward this so its part of the bug tracker. On Fri, May 24, 2019 at 08:55:22PM +0800, Jason Zaman wrote: On Fri, May 24, 2019 at 01:17:00PM +0200, Laurent Bigonville wrote: Hello, There is currently some discussion at [0] about SELinux integration in sysVinit and the fact that somebody wants to delegate the loading of the policy to an other binary than PID1. Has somebody a remark or an objection to that proposal? I object too. There is a *huge* change in functionality. Originally if you boot with SELinux enforcing, there are only two things that can happen. Either you end up with the policy loaded or the machine halts. In the new patch, an attacker can just chmod -x /sbin/selinux-check then next boot there will be no selinux enabled. if (access(SELINUX_CHECK, X_OK) != 0) fails, the machine will continue to boot without SELinux enabled. There is no difference between a user without /sbin/selinux-check on purpose and an attacker just chmod -x'd the tool. NB even amending the patch to use F_OK still leaves one vulnerable to an attacker doing rm /sbin/selinux-check to silently disable SELinux on reboot. And you can't assume that anyone who can do that can already modify or replace /sbin/init; under existing policies /sbin/init has its own distinct SELinux type, which would not be assigned to /sbin/selinux-check by default (and probably shouldn't be even in newer policies since it is the entrypoint type for the init domain). SELinux does not protect /sbin anywhere near as much as /etc/selinux (and doing that would probably be impossible). You'd need to check if selinux is enabled and enforcing before skipping the loading ... which is done by calling is_selinux_enabled() which needs linking to libselinux. The important part of the original design is not selinux_init_load_policy(), its is_selinux_enabled(). If someone really wants to run sysvinit without libselinux then just switch to Gentoo, if you're on a non-selinux profile then you dont have libselinux.so. But I'd definitely not want to have this patch in Gentoo either. -- Jason I already gave my POV regarding SELinux integration in debian. Kind regards, Laurent Bigonville [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929063
Bug#929063: SELinux integration in sysVinit
Bigon asked me to forward this so its part of the bug tracker. On Fri, May 24, 2019 at 08:55:22PM +0800, Jason Zaman wrote: > On Fri, May 24, 2019 at 01:17:00PM +0200, Laurent Bigonville wrote: > > Hello, > > > > There is currently some discussion at [0] about SELinux integration in > > sysVinit and the fact that somebody wants to delegate the loading of the > > policy to an other binary than PID1. > > > > Has somebody a remark or an objection to that proposal? > > I object too. There is a *huge* change in functionality. Originally if > you boot with SELinux enforcing, there are only two things that can > happen. Either you end up with the policy loaded or the machine halts. > > In the new patch, an attacker can just chmod -x /sbin/selinux-check then > next boot there will be no selinux enabled. > > if (access(SELINUX_CHECK, X_OK) != 0) fails, the machine will continue > to boot without SELinux enabled. There is no difference between a user > without /sbin/selinux-check on purpose and an attacker just chmod -x'd > the tool. > > SELinux does not protect /sbin anywhere near as much as /etc/selinux > (and doing that would probably be impossible). You'd need to check if > selinux is enabled and enforcing before skipping the loading ... which > is done by calling is_selinux_enabled() which needs linking to > libselinux. The important part of the original design is not > selinux_init_load_policy(), its is_selinux_enabled(). > > If someone really wants to run sysvinit without libselinux then just > switch to Gentoo, if you're on a non-selinux profile then you dont have > libselinux.so. But I'd definitely not want to have this patch in Gentoo > either. > > -- Jason > > > > I already gave my POV regarding SELinux integration in debian. > > > > Kind regards, > > > > Laurent Bigonville > > > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929063 > >
