Re: Possible system call interface for LSM

pollardat_private

Seth Arnold <sarnoldat_private>:
> On Sat, Aug 11, 2001 at 01:20:00AM +0000, David Wagner wrote:
> > Here we would have to tell admins that they can rmmod a LSM, but to
> > install a new LSM they have to reboot (or else kill all process that
> > might have used an extended syscall).  The need to reboot every time
> > you rmmod a LSM seems pretty ugly.
> 
> But it does make sense to ask the admins to stop running module-specific
> applications when changing modules.

How is that any different than when changing file system modules?

"Don't mount dosfs if you have riserfs loaded instead.. and dosfs isn't loaded"

I do agree that:

	1. The execuatble should fail if the corresponding module is not
	   loaded.
	2. There should be a way to determine if the module is loaded
	   (/proc/modules is reasonable for all but embedded systems)
	3. The module loaded should be able to prevent itself from being
	   unloaded.

I'm not going to loose any sleep over requiring:
	/proc
	/proc/<security-module-name>/...

I expect most significant modules will require multiple interfaces for
the purpose of handling a security database (not necessarily related to
inodes/files). There should be the ability to have multiple authentication
methods available (pam is nice, but very limited - no real network interface,
no remote authentication service, no third party authentication service).
Some interface SHOULD use a socket style connect, others a more syscall
structure.

ONE interface method is not enough. Many different connections will be
needed.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module