Re: [PATCH v1 0/2] Add destructor hook to LSM modules

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Paul Moore <paul@paul-moore.com>
Cc: "Mirsad Goran Todorovac" <mirsad.todorovac@alu.unizg.hr>,
	"Mirsad Goran Todorovac" <mirsad.goran.todorovac@alu.hr>,
	linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Thomas Weißschuh" <linux@weissschuh.net>,
	"Mimi Zohar" <zohar@linux.ibm.com>,
	"Casey Schaufler" <casey@schaufler-ca.com>,
	"Christian Göttsche" <cgzones@googlemail.com>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Frederick Lawler" <fred@cloudflare.com>
Subject: Re: [PATCH v1 0/2] Add destructor hook to LSM modules
Date: Mon, 13 Mar 2023 11:32:58 +0200	[thread overview]
Message-ID: <ZA7tyrscjwavzY3a@smile.fi.intel.com> (raw)
In-Reply-To: <CAHC9VhRFQtqTZku==BkW0uz1oZgG63j15GoQD1iexW4aPoAPcA@mail.gmail.com>

On Sat, Mar 11, 2023 at 09:59:17AM -0500, Paul Moore wrote:
> On Fri, Mar 10, 2023 at 5:53 PM Mirsad Goran Todorovac
> <mirsad.todorovac@alu.unizg.hr> wrote:

...

> With that out of the way, I wanted to make a quick comment on the
> patch itself.  Currently LSMs do not support unloading, or dynamic
> loading for that matter.  There are several reasons for this, but
> perhaps the most important is that in order to help meet the security
> goals for several of the LSMs they need to be present in the kernel
> from the very beginning and remain until the very end.  Adding a
> proper "release" method to a LSM is going to be far more complicated
> than what you've done with this patchset, involving a lot of
> discussion both for the LSM layer itself and all of the currently
> supported LSMs, and ultimately I don't believe it is something we will
> want to support.
> 
> I appreciate your desire to help, and I want to thank you for your
> patch and the effort behind it, but I don't believe the kobject memory
> leak you saw at kernel shutdown was a real issue (it was only "leaked"
> because the system was shutting down) and I'm not sure the current
> behavior is something we want to change in the near future.

Currently the security module so secure that even adds an unneeded noise to
the debugging output.

At very least it would be nice to add a stub and put a big comment
(on your taste) explaining why we do not do anything there.

Agree?

-- 
With Best Regards,
Andy Shevchenko