From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91DB2C61DA4 for ; Mon, 13 Mar 2023 09:35:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231186AbjCMJfP (ORCPT ); Mon, 13 Mar 2023 05:35:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230186AbjCMJet (ORCPT ); Mon, 13 Mar 2023 05:34:49 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58FB012BD8; Mon, 13 Mar 2023 02:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678699994; x=1710235994; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=F26rz5vL8ASK0vwBawwnPkZu1yacUTeFb5CHoZ+HiH0=; b=SlDJJ1A85O6yTggIhVRUVypHdLD27XC3VrHX1tNut9NpKkUbRn23JrOn 09/reILQJMq1R5D0nrLx8dE1asq5jgICQ2pELXCCW/qlVZ43SNIGZWdDX fj0Ql4aaUe+xDoxI/dLcyWyjqZ3IHidTR2doE6wbBxy2oTNUpPnCmi5R3 xM0NKNBqCyqvw280kGz/r/Y8KFZiObrh78xsHheuoGf7rPdqzKxshtBAv xdpMfiHZG39MSHnNNHrs5UgUXtJeOwGfTLM4cls7FGRkFm2Jhn1lJUY49 MLlM+PpWYZi4gg/kYwli0t6cBL2rMOSn8/bNLBoqxby42MIWWRBTcu1Od w==; X-IronPort-AV: E=McAfee;i="6500,9779,10647"; a="325459694" X-IronPort-AV: E=Sophos;i="5.98,256,1673942400"; d="scan'208";a="325459694" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2023 02:33:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10647"; a="655914665" X-IronPort-AV: E=Sophos;i="5.98,256,1673942400"; d="scan'208";a="655914665" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga006.jf.intel.com with ESMTP; 13 Mar 2023 02:33:01 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pbeY6-002Xjv-27; Mon, 13 Mar 2023 11:32:58 +0200 Date: Mon, 13 Mar 2023 11:32:58 +0200 From: Andy Shevchenko To: Paul Moore Cc: Mirsad Goran Todorovac , Mirsad Goran Todorovac , linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, Greg Kroah-Hartman , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Mimi Zohar , Casey Schaufler , Christian =?iso-8859-1?Q?G=F6ttsche?= , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , Frederick Lawler Subject: Re: [PATCH v1 0/2] Add destructor hook to LSM modules Message-ID: References: <20230310192614.GA528@domac.alu.hr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: 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 > 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