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 >
