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 > >
