Re: [RFC] LSM changes for 2.5.38

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Valdis.Kletnieks@vt.edu
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, linux-security-module@wirex.com
Subject: Re: [RFC] LSM changes for 2.5.38
Date: 30 Sep 2002 15:51:11 +0100	[thread overview]
Message-ID: <1033397471.16947.7.camel@irongate.swansea.linux.org.uk> (raw)
In-Reply-To: <200209301419.g8UEJI6E001699@turing-police.cc.vt.edu>

On Mon, 2002-09-30 at 15:19, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 27 Sep 2002 19:59:19 BST, Christoph Hellwig said:
> 
> > insmod doesn't require modules to be in /lib/modules.
> 
> This would probably be closed by this code in sys_create_module():
> 
>         /* check that we have permission to do this */
>         error = security_ops->module_ops->create_module(name, size);
>         if (error)
>                 goto err1;

This is part of the problem as ever. The name that is used is
meaningless. The module loader needs to make meaningful decisions. That
really means it needs to be able to see the actual loaded module. If we
go to Rusty's kernel module loader then we can fix this because we can
pass the actual module code/data block and sizes to the LSM. At that
point the LSM can do meaningful things like GPG.

In the current form you can say that module creation can only be done by
the right kind of user, and the program "insmod", but even in this case
the module name fed to the LSM seems worthless