Re: [PATCH try #2] security: Convert LSM into a static interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux