<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://kerneltrap.org"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>KernelTrap - SELinux</title>
 <link>http://kerneltrap.org/taxonomy/term/996/0</link>
 <description></description>
 <language>en-local</language>
<item>
 <title>Quote: I Don&#039;t Care About AppArmor</title>
 <link>http://kerneltrap.org/Quote%3A%20I%20Don%27t%20Care%20About%20AppArmor</link>
 <description>&lt;!-- google_ad_section_start --&gt;&lt;p&gt;&quot;Frankly I don&#039;t care about apparmor, I don&#039;t see it as a serious project. Smack is kind of neat but looks like a nicer way to specify selinux rules.&quot;&lt;/p&gt;
&lt;!-- google_ad_section_end --&gt;</description>
 <comments>http://kerneltrap.org/Quote%3A%20I%20Don%27t%20Care%20About%20AppArmor#comments</comments>
 <category domain="http://kerneltrap.org/Alan_Cox">Alan Cox</category>
 <category domain="http://kerneltrap.org/AppArmor">AppArmor</category>
 <category domain="http://kerneltrap.org/Linux">Linux</category>
 <category domain="http://kerneltrap.org/quote">quote</category>
 <category domain="http://kerneltrap.org/security">security</category>
 <category domain="http://kerneltrap.org/SELinux">SELinux</category>
 <category domain="http://kerneltrap.org/Smack">Smack</category>
 <category domain="http://kerneltrap.org/taxonomy/term/1102">Alan Cox</category>
 <category domain="http://kerneltrap.org/taxonomy/term/1094">linux-kernel</category>
 <pubDate>Tue, 23 Oct 2007 04:40:50 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">14651 at http://kerneltrap.org</guid>
</item>
<item>
 <title>Linux Security Modules Sans Modules</title>
 <link>http://kerneltrap.org/Linux/Linux_Security_Modules_Sans_Modules</link>
 <description>&lt;div class=&quot;taxonomy-images&quot;&gt;&lt;a href=&quot;/news/linux&quot; class=&quot;taxonomy-image-links&quot;&gt;&lt;img src=&quot;http://kerneltrap.org/files/category_pictures/K-Linux.gif&quot; alt=&quot;Linux news&quot; title=&quot;Linux news&quot;  width=&quot;75&quot; height=&quot;75&quot; /&gt;&lt;/a&gt;&lt;/div&gt;&lt;!-- google_ad_section_start --&gt;&lt;p&gt;In a brief follow up to the earlier &lt;a href=&quot;http://kerneltrap.org/Linux/Pluggable_Security&quot;&gt;pluggable security&lt;/a&gt; discussion, Thomas Fricaccia reflected on the implications for the various security frameworks, &quot;&lt;i&gt;I noticed James Morris&#039; proposal to eliminate the LSM in favor of ordaining SELinux as THE security framework forever and amen, followed by the definitive decision by Linus that LSM would remain.&lt;/i&gt;&quot;  He then commented on a recent merged patch preventing the loading of security modules into a running kernel, &quot;&lt;i&gt;but then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks.  Yikes!  Since then, I&#039;ve been following the rush to put SMACK, TOMOYO and AppArmor &#039;in-tree&#039;.&lt;/i&gt;&quot;  Linus Torvalds replied:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE people were ok with it (AppArmor), but I&#039;m with you - I applied it, but I&#039;m also perfectly willing to unapply it if there actually are valid out-of-tree users that people push for not merging.  So Í don&#039;t think this is settled in any way - please keep discussing, and bringing it up. I&#039;m definitely not in the camp that thinks that LSM needs to be &#039;controlled&#039;, but on the other hand, I&#039;m also not going to undo that commit unless there are good real arguments for undoing it (not just theoretical ones).&lt;/p&gt;
&lt;p&gt;&quot;For example, I do kind of see the point that a &#039;real&#039; security model might want to be compiled-in, and not something you override from a module. Of course, I&#039;m personally trying to not use any modules at all, so I&#039;m just odd and contrary, so whatever..  Real usage scenarios with LSM modules, please speak up!&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://kerneltrap.org/Linux/Linux_Security_Modules_Sans_Modules&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://kerneltrap.org/Linux/Linux_Security_Modules_Sans_Modules#comments</comments>
 <category domain="http://kerneltrap.org/AppArmor">AppArmor</category>
 <category domain="http://kerneltrap.org/James_Morris">James Morris</category>
 <category domain="http://kerneltrap.org/Linus_Torvalds">Linus Torvalds</category>
 <category domain="http://kerneltrap.org/Linux">Linux</category>
 <category domain="http://kerneltrap.org/LSM">LSM</category>
 <category domain="http://kerneltrap.org/modules">modules</category>
 <category domain="http://kerneltrap.org/security">security</category>
 <category domain="http://kerneltrap.org/SELinux">SELinux</category>
 <category domain="http://kerneltrap.org/Smack">Smack</category>
 <category domain="http://kerneltrap.org/taxonomy/term/1088">Thomas Fricaccia</category>
 <category domain="http://kerneltrap.org/TOMOYO_Linux">TOMOYO Linux</category>
 <category domain="http://kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Sat, 20 Oct 2007 01:32:21 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">14619 at http://kerneltrap.org</guid>
</item>
<item>
 <title>Pluggable Security</title>
 <link>http://kerneltrap.org/Linux/Pluggable_Security</link>
 <description>&lt;div class=&quot;taxonomy-images&quot;&gt;&lt;a href=&quot;/news/linux&quot; class=&quot;taxonomy-image-links&quot;&gt;&lt;img src=&quot;http://kerneltrap.org/files/category_pictures/K-Linux.gif&quot; alt=&quot;Linux news&quot; title=&quot;Linux news&quot;  width=&quot;75&quot; height=&quot;75&quot; /&gt;&lt;/a&gt;&lt;/div&gt;&lt;!-- google_ad_section_start --&gt;&lt;p&gt;&quot;&lt;i&gt;I think the decision to merge Smack is something that needs to be considered in the wider context of overall security architecture,&lt;/i&gt;&quot; &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2007/10/1/326293&quot;&gt;suggested James Morris&lt;/a&gt; following Andrew Morton&#039;s recent comment that he plans to merge the functionality in the upcoming 2.6.24 kernel.  While James had no complaints about Smack itself, he expressed concerns regarding the pluggable nature of LSM, which is used by Smack, cautioning, &quot;&lt;i&gt;if LSM remains, security will never be a first class citizen of the kernel,&lt;/i&gt;&quot; adding, &quot;&lt;i&gt;on a broader scale, we&#039;ll miss the potential of Linux having a coherent, semantically strong security architecture.&lt;/i&gt;&quot;  He noted that he&#039;d rather see SELinux as the sole Linux security framework, &quot;&lt;i&gt;merging Smack, however, would lock the kernel into the LSM API.  Presently, as SELinux is the only in-tree user, LSM can still be removed.&lt;/i&gt;&quot;&lt;/p&gt;
&lt;p&gt;Linus Torvalds firmly stated, &quot;&lt;i&gt;LSM stays in. No ifs, buts, maybes or anything else.&lt;/i&gt;&quot;  He explained, &quot;&lt;i&gt;you security people are insane. I&#039;m tired of this &#039;only my version is correct&#039; crap. The whole and only point of LSM was to get away from that.&lt;/i&gt;&quot;  Linus continued, &quot;&lt;i&gt;I guess I have to merge AppArmor and SMACK just to get this *disease* off the table. You&#039;re acting like a string theorist, claiming that t here is no other viable theory out there. Stop it. It&#039;s been going on for too damn long.&lt;/i&gt;&quot;  Stephen Smalley responded, &quot;&lt;i&gt;you argued against pluggable schedulers, right?  Why is security different?&lt;/i&gt;&quot;  Linus explained:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;Schedulers can be objectively tested. There&#039;s this thing called &#039;performance&#039;, that can generally be quantified on a load basis.&lt;/p&gt;
&lt;p&gt;&quot;Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real nu