All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH] selinux: reorder hooks to make runtime disable less broken
Date: Tue, 10 Dec 2019 14:29:15 -0500	[thread overview]
Message-ID: <CAHC9VhRe=xdz9eD9q8mO8=3QDVfsRpn7OUyXDj7o4C-cYfFHMQ@mail.gmail.com> (raw)
In-Reply-To: <CAFqZXNvMHEvv0tP7ybFEsH1-CvE5GGC9fEP=yXqEnQmjxgdDjA@mail.gmail.com>

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.

-- 
paul moore
www.paul-moore.com

  reply	other threads:[~2019-12-10 19:29 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 [this message]
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='CAHC9VhRe=xdz9eD9q8mO8=3QDVfsRpn7OUyXDj7o4C-cYfFHMQ@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=omosnace@redhat.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.