From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 2 Oct 2018 03:58:52 +1000 (AEST) From: James Morris To: Casey Schaufler cc: Tetsuo Handa , Kees Cook , LSM , SE Linux , LKLM , John Johansen , Paul Moore , Stephen Smalley , "linux-fsdevel@vger.kernel.org" , Alexey Dobriyan , =?ISO-8859-15?Q?Micka=EBl_Sala=FCn?= , Salvatore Mesoraca Subject: Re: [PATCH v4 00/19] LSM: Module stacking for SARA and Landlock In-Reply-To: Message-ID: References: <680e6e16-0890-8304-0e8e-6c58966813b5@schaufler-ca.com> <39457e79-3816-824b-6b4d-89d21b03f9ce@i-love.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: On Sun, 23 Sep 2018, Casey Schaufler wrote: > > How do you plan to handle LKM-based LSMs? > > My position all along has been that I don't plan to handle LKM > based LSMs, but that I won't do anything to prevent someone else > from adding them later. I believe that I've done that. Several > designs, including a separate list for dynamically loaded modules > have been proposed. I think some of those would work. Dynamically loadable LSMs are a bad idea, per several previous discussions. As a general design concept, kernel security mechanisms should be invoked during boot, so we can reason about the overall state of the system at a given point. In any case, we do not need to take dynamic LSMs into account at this stage. We don't build infrastructure for non-existent features.