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

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Kyle Moffett (mrmacman_g4@mac.com):
> 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"?

Read the sentence right above yours again.

Noone is saying we should be able to 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?>

Those don't all need labels for capabilities, for instance.  This
question is as wrong as the last one.

> 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  

No, your argument sounds like "my fs can't be a module so neither should
any."

> 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-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html