Kyle Moffett wrote: > Let's go over the differences between "my fs" and "my LSM", and the > similarities between "my VM" and "my LSM": Filesystems don't get > hooked from virtually every userspace-initiated operation, whereas > both VMs and LSMs do. VMs and LSMs attach anonymous state data to a > large percentage of the allocated objects in the system, whereas > filesystems allocate their own independent datastructure and use > that. Would you want to "rmmod ext3" and then "modprobe ext2" while > you have an ext2-as-ext3 filesystem *mounted*??? If you want a good > analogy, that's a better one than the "my fs can't be a module" crap. > > This whole discussion boils down to 2 points: > 1) As currently implemented, no LSM may be safely rmmod-ed > 2) Someone has submitted a patch which fixes that problem (you can't > rmmod them at all, so no crashes) > > If you really want to do modular LSMs, then you need to submit a patch > which fixes all the race conditions in LSM removal *without* adding > much extra overhead. I'm sure if your solutions works then everyone > will be much more open to modular LSMs. I said this before: Hmmm. You seem to be mostly concerned with safely rmmod'ing modules. In contrast, my main concern with the proposed patch is that it removes the ability to *insert* a module.
Consider the use case of joe admin who is running enterprise-supported RHEL or SLES, and wants to try some newfangled LSM FooSecureMod thingie. So he grabs a machine, config's selinux=0 or apparmor=0 and loads his own module on boot, and plays with it. He even likes FooSecure, better than SELinux or AppArmor, and wants to roll it out across his data center. Without James's patch, he can do that, and at worst has a tainted kernel. RH or Novell or his favorite distro vendor can fix that with a wave of the hand and bless FooSecure as a module. With James's patch, he has to patch his kernels, and then enterprise support is hopeless, to say nothing of the barrier to entry that "patch and rebuild kernel" is more than many admins are willing to do. So to solve the problem James & Kyle are concerned with, and preserve user choice, how about we *only* remove the ability to rmmod, and leave in place the ability to modprobe? Or even easier, LSMs that don't want to be unloaded can just block rmmod, and simple LSMs that can be unloaded safely can permit it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
