On Jun 26, 2007, at 09:47:12, Serge E. Hallyn wrote:
Ok, so say we extend LSM to do what AppArmor or TOMOYO need, what do
you expect to happen when you "rmmod tomoyo", "rmmod apparmor", or
whatever? Each of those is also going to stick lots of context on
various objects during the course of running, the same way that the
VM subsystem sticks lots of context on filesystem pages while
running. Besides, even the standard "capabilities" module wants to
attach a list of capabilities to every process and defines
inheritance rules for them. Ergo you have the problems described below:
Ok, so let's just restrict ourselves to the simple dumb-as-dirt
capabilities module. Every process is "labeled" with capabilities
while running under that LSM, right? What happens when you "rmmod
capabilities"? Do you iterate over all the processes to remove their
security data even while they may be using it? Or do you just let it
leak? Some daemons test if capabilities are supported, and if so
they modify their capability set instead of forking a high-priv and a
low-priv process and doing IPC. When you remove the capabilities
module, suddenly all those programs will lose that critical "low-
privilege" data and become full root. What happens later when you
"modprobe capabilities"? Do you suddenly have to stop the system
while you iterate over EVERY process to set capabilities based on
whether it's root or not? It's also impossible to determine from a
given state in time what processes should have capabilities, as the
model includes inheritance, which includes processes that don't even
exist anymore.
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:
Cheers,
Kyle Moffett
-
