On Jun 26, 2007, at 09:47:12, Serge E. Hallyn wrote:
Quoting Kyle Moffett ([email protected]):
On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote:
It's useful for some LSMs to be modular, and LSMs which are y/n
options won't have any security architecture issues with
unloading at all. The mere fact that SELinux cannot be built as a
module is a rather weak argument for disabling LSM modules as a
whole, so please don't.
Here are a few questions for you:
1) What do you expect to happen to all the megs of security
data when you "rmmod selinux"?
Read the sentence right above yours again.
Noone is saying we should be able to rmmod selinux.
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:
Do you maintain a massive linked list of security data (with all
the locking and performance problems) so that you can iterate over
it calling kfree()? What synchronization primitive do we have
right now which could safely stop all CPUs outside of security
calls while we NULL out and free security data and disable
security operations? Don't say "software suspend" and "process
freezer", since those have whole order-of-magnitude-complexity
problems of their own (and don't always work right either).
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?
Those don't all need labels for capabilities, for instance. This
question is as wrong as the last one.
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.
3) This sounds suspiciously like "The mere fact that the
Linux-2.6-VM cannot be built as a module is a rather weak argument
for disabling VFS modules as a whole".
No, your argument sounds like "my fs can't be a module so neither
should any."
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:
So... Do you have a proposal for solving those rather fundamental
design gotchas? If so, I'm sure everybody here would love to see
your patch
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
