On Thu, Dec 12, 2019 at 7:18 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Thu, Dec 12, 2019 at 1:10 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > On 12/12/19 1:09 PM, Paul Moore wrote: > > > On Thu, Dec 12, 2019 at 12:57 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > >> On 12/12/19 12:54 PM, Paul Moore wrote: > > >>> ... > > >>> Just so I'm understanding this thread correctly, the above change > > >>> (adding enabled checks to each SELinux hook implementation) is only > > >>> until Fedora can figure out a way to deprecate and remove the runtime > > >>> disable? > > >> > > >> That's my understanding. In the interim, Android kernels should already > > >> be disabling CONFIG_SECURITY_SELINUX_DISABLE and other distros may > > >> choose to disable it as long as they don't care about supporting SELinux > > >> runtime disable. > > > > > > Okay, I just wanted to make sure I wasn't missing something. > > > Honestly, I'd rather Fedora just go ahead and do whatever it is they > > > need to do to turn off CONFIG_SECURITY_SELINUX_DISABLE (it sounds like > > > they have a plan and are working on it), I'm not overly excited about > > > temporarily cluttering up the code with additional "enabled" checks > > > when the status quo works, even if it is less than ideal. > > > > The status quo is producing kernel crashes, courtesy of LSM stacking > > changes... > > How prevalent are these crashes? I don't think they are prevalent, we only received one report for RHEL and it came in ~ 6 months after 8.0 was released, which was the first release that had the stacking patch. I wasn't able to reproduce it without adding delays between the hook removals. However, the report may have some specific configuration where it happens more often due to just the "right" timing of some events... > > This also only happens when disabling SELinux at runtime, yes? > Something we've advised against for some time now and are working to > eliminate? Let's just get rid of the runtime disable *soon*, and if > we need a stop-gap fix let's just go with the hook reordering since > that seems to minimize the impact, if not resolve it. > > I'm not going to comment on the stacking changes. -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.
