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 25, 2007, at 16:37:58, Andreas Gruenbacher wrote:
On Monday 25 June 2007 06:33, James Morris wrote:
Convert LSM into a static interface, as the ability to unload a security module is not required by in-tree users and potentially complicates the overall security architecture.

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"? 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? 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.

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". We don't do "pluggable fundamental infrastructure" in Linux. If it's fundamental infrastructure then you eliminate as many differences as possible and leave the rest to CONFIG options (or delete it entirely).


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; though maybe not if it's a 32MB patch-zilla-of-doom (AKPM beware, the merge-conflict-from-hell is on its way). On the other hand, if you accept that these problems basically can't be solved and we make things static and rip out a bunch of code, we can probably improve our performance under larger security models (like SELinux/ AppArmor/TOMOYO/MagicSecurityFlavorOfTheWeek(TM)) by a percent or two.

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