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