<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.kerneltrap.org"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>KernelTrap - Smack</title>
 <link>http://www.kerneltrap.org/taxonomy/term/1024/0</link>
 <description></description>
 <language>en-local</language>
<item>
 <title>Quote: I Don&#039;t Care About AppArmor</title>
 <link>http://www.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://www.kerneltrap.org/Quote%3A%20I%20Don%27t%20Care%20About%20AppArmor#comments</comments>
 <category domain="http://www.kerneltrap.org/Alan_Cox">Alan Cox</category>
 <category domain="http://www.kerneltrap.org/AppArmor">AppArmor</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/quote">quote</category>
 <category domain="http://www.kerneltrap.org/security">security</category>
 <category domain="http://www.kerneltrap.org/SELinux">SELinux</category>
 <category domain="http://www.kerneltrap.org/Smack">Smack</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/1102">Alan Cox</category>
 <category domain="http://www.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://www.kerneltrap.org</guid>
</item>
<item>
 <title>Linux Security Modules Sans Modules</title>
 <link>http://www.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://www.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://www.kerneltrap.org/Linux/Linux_Security_Modules_Sans_Modules#comments</comments>
 <category domain="http://www.kerneltrap.org/AppArmor">AppArmor</category>
 <category domain="http://www.kerneltrap.org/James_Morris">James Morris</category>
 <category domain="http://www.kerneltrap.org/Linus_Torvalds">Linus Torvalds</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/LSM">LSM</category>
 <category domain="http://www.kerneltrap.org/modules">modules</category>
 <category domain="http://www.kerneltrap.org/security">security</category>
 <category domain="http://www.kerneltrap.org/SELinux">SELinux</category>
 <category domain="http://www.kerneltrap.org/Smack">Smack</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/1088">Thomas Fricaccia</category>
 <category domain="http://www.kerneltrap.org/TOMOYO_Linux">TOMOYO Linux</category>
 <category domain="http://www.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://www.kerneltrap.org</guid>
</item>
<item>
 <title>Smack Updates</title>
 <link>http://www.kerneltrap.org/Linux/Smack_Updates</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;Casey Schaufler posted &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2007/10/4/329571&quot;&gt;an updated Smack patchset&lt;/a&gt; based on feedback from the previous posting, &quot;&lt;i&gt;I have broken the Smack patch into the netlabel changes from Paul Moore (1/2) and the Smack LSM (2/2), at Paul&#039;s kind suggestion.&lt;/i&gt;&quot;  He added:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;The smackfs symlinks have proven too contentious. I have removed the facility. Al and Alan are correct that the rich set of mount options currently available can handle any of the use cases I was looking at without excessive difficulty.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Smack is the Simplified Mandatory Access Control Kernel, utilizing the LSM framework to implement label-based mandatory access control and slated for inclusion in the upcoming 2.6.24 mainline kernel during the 2.6.24-rc1 merge window.&lt;/p&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://www.kerneltrap.org/Linux/Smack_Updates&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Linux/Smack_Updates#comments</comments>
 <category domain="http://www.kerneltrap.org/2.6.24">2.6.24</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/1026">Casey Schaufler</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/LSM">LSM</category>
 <category domain="http://www.kerneltrap.org/merge_window">merge window</category>
 <category domain="http://www.kerneltrap.org/security">security</category>
 <category domain="http://www.kerneltrap.org/Smack">Smack</category>
 <category domain="http://www.kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Fri, 05 Oct 2007 00:33:34 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">14515 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>Pluggable Security</title>
 <link>http://www.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 numbers.  So the difference between them is simple: one is &#039;hard science&#039;. The other one is &#039;people wanking around with their opinions&#039;.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://www.kerneltrap.org/Linux/Pluggable_Security&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Linux/Pluggable_Security#comments</comments>
 <category domain="http://www.kerneltrap.org/2.6.24">2.6.24</category>
 <category domain="http://www.kerneltrap.org/James_Morris">James Morris</category>
 <category domain="http://www.kerneltrap.org/Linus_Torvalds">Linus Torvalds</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/LSM">LSM</category>
 <category domain="http://www.kerneltrap.org/security">security</category>
 <category domain="http://www.kerneltrap.org/SELinux">SELinux</category>
 <category domain="http://www.kerneltrap.org/Smack">Smack</category>
 <category domain="http://www.kerneltrap.org/Stephen_Smalley">Stephen Smalley</category>
 <category domain="http://www.kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Mon, 01 Oct 2007 12:49:37 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">14488 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>Simplified Mandatory Access Control Kernel</title>
 <link>http://www.kerneltrap.org/Linux/Simplified_Mandatory_Access_Control_Kernel</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;Smack is the Simplified Mandatory Access Control Kernel,&lt;/i&gt;&quot; Casey Schaufler said &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2007/9/29/325567&quot;&gt;posting the third version of his patchest&lt;/a&gt;.  He explained, &quot;&lt;i&gt;Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data.&lt;/i&gt;&quot;  Casey continued:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;Smack is implemented as a clean LSM. It requires no external code changes and the patch modifies only the Kconfig and Makefile in the security directory. Smack uses extended attributes and provides a set of general mount options, borrowing technics used elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides a pseudo-filesystem smackfs that is used for manipulation of system Smack attributes.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Andrew Morton replied to Casy&#039;s lengthy description, &quot;&lt;i&gt;I don&#039;t know enough about security even to be dangerous.  I went back and reviewed the August thread from your version 1 submission and the message I