[ Sorry, if I messed quotation. It is complex ]
[2019-05-24 21:00] Jason Zaman <jason@xxxxxxxxxxxxx>
> > > 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
--
