On Jun 26, 2007, at 20:57:53, Crispin Cowan wrote:
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.
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.
You must have missed this in my emails:
2) When you "modprobe my_custom_security_module", how exactly do
you expect that all the processes, files, shared memory segments,
file descriptors, sockets, SYSV mutexes, packets, etc will get
appropriate security pointers? This isn't even solvable the same
way the "rmmod" problem is, since most of that isn't even
accessible without iterating over the ENTIRE dcache, icache, every
process, every process' file-descriptors, every socket, every unix
socket, every anonymous socket, every SYSV shm object, every
currently-in-process packet.
I'd argue that security-module-insertion is actually MORE complicated
than removal. Here's one example: TOMOYO cares about the process
execution tree, but you can't penalize the no-LSM case by a percent
or two to add that kind of data. When TOMOYO is loaded, it wants to
do access control based on process execution trees for which data
DOES NOT EXIST!!! Not only that, but the processes which originally
ran the one you care about (and which you'd need to recreate that
data) may have exited anywhere from seconds to years before. It is
fundamentally IMPOSSIBLE to recreate that data, even if you could
solve the problems of how to do it while the system is running
without racing with existing process operations. Imagine a process
which hasn't had security data tagged to it yet which opens thousands
of FIFOs per second, waits for your tagging code to assign security
data to them in the filesystem, and then removes them; if you did it
right you could prevent the code from EVER completely tagging every
object (even assuming you could recreate enough information).
Such a need to add extra security data to multiple classes of objects
is *fundamental* to any security module (isn't that the whole
point?) As such, you can't just "modprobe" one and expect it to
work. That's like mounting an ext2 filesystem, and then later trying
to "modprobe ext3" and dynamically switch to the ext3 code and enable
journalling all at once ON THE MOUNTED FILESYSTEM!!!
Sure, theoretically it *could* be done, but the code complexity is
hardly worth it (plus nobody has yet even tried posting patches to
make it happen).
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.
Flatly impossible. You simply cannot "load" a security module and
hope to provide any useful information about the system's present
state. If you want comprehensive security it has to be there before
a single byte of userspace code is executed. SELinux sort-of handles
unlabelled objects by treating them with a small set of initial
"types", but that's only enough to get the system up enough to
actually relabel objects with type-transitions (after init loads the
selinux policy it reexecs itself, before doing anything else).
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.
An LSM simple enough to unload would be too simple for anybody to
want to load in the first place (even capabilities can have this
problem). What kind of security module would you load that doesn't
need to add security data to objects?
Then of course there's also the -ENOPATCH problem.
Cheers,
Kyle Moffett
-
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/
