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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jun 2007 08:47:12 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Kyle Moffett <mrmacman_g4@....com>
Cc:	Andreas Gruenbacher <agruen@...e.de>,
	James Morris <jmorris@...ei.org>,
	Chris Wright <chrisw@...s-sol.org>,
	linux-security-module@...r.kernel.org,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Andrew Morgan <agm@...gle.com>,
	Andrew Morton <akpm@...gle.com>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	lkml <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Greg KH <greg@...ah.com>, Eric Paris <eparis@...hat.com>
Subject: Re: [PATCH try #2] security: Convert LSM into a static interface

Quoting Kyle Moffett (mrmacman_g4@....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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/