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

Kyle Moffett
2007-06-26T04:10:08Z

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