* Re: SELinux integration in sysVinit
2019-05-24 13:00 ` Jason Zaman
@ 2019-05-24 13:40 ` Stephen Smalley
2019-05-29 3:40 ` Bug#929063: " Dmitry Bogatov
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: Stephen Smalley @ 2019-05-24 13:40 UTC (permalink / raw)
To: Jason Zaman, Laurent Bigonville; +Cc: selinux, 929063
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
>>>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Bug#929063: SELinux integration in sysVinit
2019-05-24 13:00 ` Jason Zaman
2019-05-24 13:40 ` Stephen Smalley
@ 2019-05-29 3:40 ` Dmitry Bogatov
2019-05-29 3:40 ` Dmitry Bogatov
2019-05-29 3:40 ` Dmitry Bogatov
3 siblings, 0 replies; 7+ messages in thread
From: Dmitry Bogatov @ 2019-05-29 3:40 UTC (permalink / raw)
To: Jason Zaman, 929063; +Cc: Laurent Bigonville, selinux
[ 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
--
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Bug#929063: SELinux integration in sysVinit
2019-05-24 13:00 ` Jason Zaman
2019-05-24 13:40 ` Stephen Smalley
2019-05-29 3:40 ` Bug#929063: " Dmitry Bogatov
@ 2019-05-29 3:40 ` Dmitry Bogatov
2019-05-29 3:40 ` Dmitry Bogatov
3 siblings, 0 replies; 7+ messages in thread
From: Dmitry Bogatov @ 2019-05-29 3:40 UTC (permalink / raw)
To: Jason Zaman, 929063; +Cc: Laurent Bigonville, selinux
[ 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
--
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Bug#929063: SELinux integration in sysVinit
2019-05-24 13:00 ` Jason Zaman
` (2 preceding siblings ...)
2019-05-29 3:40 ` Dmitry Bogatov
@ 2019-05-29 3:40 ` Dmitry Bogatov
3 siblings, 0 replies; 7+ messages in thread
From: Dmitry Bogatov @ 2019-05-29 3:40 UTC (permalink / raw)
To: Jason Zaman, 929063; +Cc: Laurent Bigonville, selinux, kaction
[ 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
--
^ permalink raw reply [flat|nested] 7+ messages in thread