From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: Preview of changes to the Security susbystem for 2.6.36 Date: Tue, 3 Aug 2010 10:07:49 -0700 Message-ID: <20100803170749.GI3948@outflux.net> References: <20100802063224.GR3948@outflux.net> <20100802065746.GS3948@outflux.net> <4C569BCA.3050603@ontolinux.com> <20100802163602.GU3948@outflux.net> <4C570166.8050105@ontolinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: James Morris , linux-kernel , linux-fsdevel , linux-security-module To: Christian Stroetmann Return-path: Content-Disposition: inline In-Reply-To: <4C570166.8050105@ontolinux.com> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Aug 02, 2010 at 07:33:26PM +0200, Christian Stroetmann wrote: > structure of the other LSMs, especially if it becomes large and in > this way important to be followed by only growing it with > functionalities taken from other security packages. If you say that > the way of the Yama LSM is the right way to do it in general, then > we don't need a new LSM like Yama, but a new LSM architecture. Well, trying to get these protections into mainline does seem to be demonstrating a need for some kind of security architecture that isn't LSM. As for chaining, I was considering introducing basic "first non-zero return code wins" chain of LSMs, but the chain could include only up to 1 LSM that implements the proc attr hook (though the prctl handler isn't non-zero but rather non-ENOSYS). -Kees -- Kees Cook Ubuntu Security Team