All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Mosnacek <omosnace@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: SElinux list <selinux@vger.kernel.org>, Paul Moore <paul@paul-moore.com>
Subject: Re: [PATCH] selinux: reorder hooks to make runtime disable less broken
Date: Tue, 10 Dec 2019 12:19:36 +0100	[thread overview]
Message-ID: <CAFqZXNvMHEvv0tP7ybFEsH1-CvE5GGC9fEP=yXqEnQmjxgdDjA@mail.gmail.com> (raw)
In-Reply-To: <23671223-f841-564c-6ae8-0401bce0fa20@tycho.nsa.gov>

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]). So considering the
removal is going to take some time, I'd prefer to at least stop the
kernel from crashing in the meantime.

I do plan to seriously look at removing the runtime disable entirely,
but that is a longer-term goal. Restoring the logical hook order would
be trivial once the removal is done.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1430944#c2

--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.


  parent reply	other threads:[~2019-12-10 11:19 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 [this message]
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

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='CAFqZXNvMHEvv0tP7ybFEsH1-CvE5GGC9fEP=yXqEnQmjxgdDjA@mail.gmail.com' \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.