SELinux integration in sysVinit

SELinux integration in sysVinit

[Laurent Bigonville]

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 already gave my POV regarding SELinux integration in debian.

Kind regards,

Laurent Bigonville

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929063

Re: SELinux integration in sysVinit

[Jason Zaman]

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
> 

Re: SELinux integration in sysVinit

[Jason Zaman]

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

Re: SELinux integration in sysVinit

[Stephen Smalley]

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

Re: Bug#929063: SELinux integration in sysVinit

[Dmitry Bogatov]

[ Sorry, if I messed quotation. It is complex ]

[2019-05-24 21:00] Jason Zaman <jason@perfinion.com>

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

Re: Bug#929063: SELinux integration in sysVinit

[Dmitry Bogatov]

[ Sorry, if I messed quotation. It is complex ]

[2019-05-24 21:00] Jason Zaman <jason@perfinion.com>

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

Re: Bug#929063: SELinux integration in sysVinit

[Dmitry Bogatov]

[ Sorry, if I messed quotation. It is complex ]

[2019-05-24 21:00] Jason Zaman <jason@perfinion.com>

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