From: Casey Schaufler <casey@schaufler-ca.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
Paul Moore <paul@paul-moore.com>,
Ondrej Mosnacek <omosnace@redhat.com>
Cc: SElinux list <selinux@vger.kernel.org>,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] selinux: reorder hooks to make runtime disable less broken
Date: Tue, 10 Dec 2019 11:57:46 -0800 [thread overview]
Message-ID: <658a7738-9582-0b16-3803-649e89fbc250@schaufler-ca.com> (raw)
In-Reply-To: <9669d08f-6411-f381-2f2a-59ab1d3fe337@tycho.nsa.gov>
On 12/10/2019 11:50 AM, Stephen Smalley wrote:
> On 12/10/19 2:43 PM, Casey Schaufler wrote:
>> On 12/10/2019 11:29 AM, Paul Moore wrote:
>>> On Tue, Dec 10, 2019 at 6:19 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>>>> On Mon, Dec 9, 2019 at 2:21 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>>> On 12/9/19 2:57 AM, Ondrej Mosnacek wrote:
>>>>>> Commit b1d9e6b0646d ("LSM: Switch to lists of hooks") switched the LSM
>>>>>> infrastructure to use per-hook lists, which meant that removing the
>>>>>> hooks for a given module was no longer atomic. Even though the commit
>>>>>> clearly documents that modules implementing runtime revmoval of hooks
>>>>>> (only SELinux attempts this madness) need to take special precautions to
>>>>>> avoid race conditions, SELinux has never addressed this.
>>>>>>
>>>>>> By inserting an artificial delay between the loop iterations of
>>>>>> security_delete_hooks() (I used 100 ms), booting to a state where
>>>>>> SELinux is enabled, but policy is not yet loaded, and running these
>>>>>> commands:
>>>>>>
>>>>>> while true; do ping -c 1 <some IP>; done &
>>>>>> echo -n 1 >/sys/fs/selinux/disable
>>>>>> kill %1
>>>>>> wait
>>>>>>
>>>>>> ...I was able to trigger NULL pointer dereferences in various places. I
>>>>>> also have a report of someone getting panics on a stock RHEL-8 kernel
>>>>>> after setting SELINUX=disabled in /etc/selinux/config and rebooting
>>>>>> (without adding "selinux=0" to kernel command-line).
>>>>>>
>>>>>> Reordering the SELinux hooks such that those that allocate structures
>>>>>> are removed last seems to prevent these panics. It is very much possible
>>>>>> that this doesn't make the runtime disable completely race-free, but at
>>>>>> least it makes the operation much less fragile.
>>>>>>
>>>>>> An alternative (and safer) solution would be to add NULL checks to each
>>>>>> hook, but doing this just to support the runtime disable hack doesn't
>>>>>> seem to be worth the effort...
>>>>> Personally, I would prefer to just get rid of runtime disable
>>>>> altogether; it also precludes making the hooks read-only after
>>>>> initialization. IMHO, selinux=0 is the proper way to disable SELinux if
>>>>> necessary. I believe there is an open bugzilla on Fedora related to
>>>>> this issue, since runtime disable was originally introduced for Fedora.
>>>> I, too, would like to see it gone, but removing it immediately would
>>>> likely cause issues for existing users (see [1]) ...
>>>>
>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1430944#c2
>>> For the record, and for those who didn't click on the RHBZ link above,
>>> I'm a big fan of getting rid of SELinux's runtime disable but concede
>>> that it must be done in such a way to as not horribly break userspace.
>>
>> Is there some reason that changing the "disable SELinux" option
>> has to remove the hooks? Why can't it set selinux_enabled to 0
>> and be done with it?
>
> selinux_enabled is only used during initialization to deal with selinux=0 across the different components of SELinux. It isn't checked by the hooks themselves. And if we were to add a if (!selinux_enabled) return 0 to the start of every hook, then that's just another easy target for kernel exploits to leverage.
That's what I expected, but I wanted to see it explicitly stated. Thanks.
prev parent reply other threads:[~2019-12-10 19:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 7:57 [PATCH] selinux: reorder hooks to make runtime disable less broken Ondrej Mosnacek
2019-12-09 7:59 ` Ondrej Mosnacek
2019-12-09 13:21 ` Stephen Smalley
2019-12-09 13:58 ` Stephen Smalley
2019-12-09 17:20 ` Casey Schaufler
2019-12-10 11:27 ` Ondrej Mosnacek
2019-12-10 16:23 ` Casey Schaufler
2019-12-09 16:32 ` Casey Schaufler
[not found] ` <CAOSEQ1pHnxrMyn1qYXzJPaT6Smf1ycVOfHQ7-gkDpzYiq9S=Cg@mail.gmail.com>
2019-12-09 17:37 ` Casey Schaufler
2019-12-10 11:19 ` Ondrej Mosnacek
2019-12-10 19:29 ` Paul Moore
2019-12-10 19:43 ` Casey Schaufler
2019-12-10 19:50 ` Stephen Smalley
2019-12-10 19:57 ` Casey Schaufler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=658a7738-9582-0b16-3803-649e89fbc250@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).