|WikiProject Software / Computing||(Rated Start-class, Low-importance)|
|WikiProject Linux||(Rated Start-class, Low-importance)|
I do not believe this section and its companion in Security-Enhanced_Linux represent a neutral point of view, but instead both appear to be written to promote the view that SELinux's object-based model is preferable to AppArmor's path-based model. Furthermore, I do not see what this discussion contributes in terms of information to either article. I would suggest simply deleting the "Criticism" section and simply have each article mention that an alternative approach exists. (See Talk:Security-Enhanced_Linux for additional discussion.)
Jcarnelian 23:53, 4 May 2007 (UTC)
I wrote the criticism section of this page, and I am the main AppArmor architect. I did it to provide balance, so the Criticism section is pretty much an unquestioning summary of what I have seen critics say about AppArmor. Ideally, I would like an actual critic of AppArmor to revise the Criticism section. My view of fair debate would be to let any factually correct text in Criticism stand, and rebutt it elsewhere.
Similarly, I would hope that the SELinux people would let stand factually valid criticisms in the Criticism section of their entry.
Crispincowan 19:00, 6 June 2007 (UTC)
OK, I tried rewriting the Criticism section from a NPOV. What do you think?
Jcarnelian 11:46, 15 July 2007 (UTC)
Best Approach Debate
I think the part this part is false, since unix and linux employ only inode-based and never path-based access control (apparmor is a path-based attempt): "While there has been considerable debate about which approach is better, there is as yet no strong evidence that either approach is preferable. Discussion about their relative merits often revolves around which approach is more aligned with existing UNIX/Linux access control mechanisms, but UNIX and Linux use a combination of path-based and inode-based access control"
Hard to imagine what the "evidence" would be apart from pointing out the conceptual incompatibility of apparmor vs unix filesystems which ultimately makes apparmor unsound. this has been done numerous times on mailing lists...
Reference 7 is erroneously attributed to "James Corbet" - should be "Jonathan Corbet" http://en.wikipedia.org/wiki/Jonathan_Corbet
- anonymous coward —Preceding unsigned comment added by 18.104.22.168 (talk) 05:20, 22 October 2009 (UTC)
"Conceptual incompatibility with the UNIX file system"? Who cares? What matters is what actually needs to be protected. For example, the specific inode associated with /etc/passwd is irrelevant; whatever is at that path is used as the password file. The fact that UNIX path-based protections are so limited right now is all the more reason to add path-based protection mechanisms, because most UNIX programs actually already make security-related assumptions based on path, not inode. Jcarnelian (talk) 02:28, 21 April 2011 (UTC)
Out of Date Remark
The "Out of Date" box was introduced by the following revision:
- 16:45, 30 October 2010 22.214.171.124 (8,376 bytes) (out of date - no info about canonical/launchpad, the lede makes the project sound dead (it isn't))