Re: [PATCH] selinux: reorder hooks to make runtime disable less broken

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 9, 2019 at 2:21 PM Stephen Smalley <sds@xxxxxxxxxxxxx> 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.





[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux