Talk:AppArmor

NPOV?

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

^ James Corbet (2010-10-20). "The 2.6.36 kernel is out". http://lwn.net/Articles/409810. —Preceding unsigned comment added by 216.191.234.70 (talk) 19:32, 7 March 2011 (UTC)

- anonymous coward  —Preceding unsigned comment added by 80.75.107.201 (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 99.231.218.239 (8,376 bytes) (out of date - no info about canonical/launchpad, the lede makes the project sound dead (it isn't))

Added reference to canonical's work. Updated stable release info. Guess this issue is fixed. --188.98.126.254 (talk) 11:42, 20 September 2011 (UTC)

Screenshot

Does AppArmor come with a UI that could be shown in a screenshot? Regards, [IP] — Preceding unsigned comment added by 94.217.250.203 (talk) 15:31, 24 November 2011 (UTC)

No, each distribution has its own AppArmor configuration GUI (or none at all). --79.214.137.231 (talk) 13:45, 24 October 2012 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on AppArmor. Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

• Attempted to fix sourcing for http://www.techrepublic.com/article/immunix-system-7-linux-security-with-a-hard-hat-not-a-red-hat/1053405

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 17:39, 30 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on AppArmor. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20110904032047/http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.36 to https://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.36

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 02:07, 8 July 2017 (UTC)

SELinux Cannot Provide MAC for Files Mounted via NFS?

I cannot comment on the validity of most of the statement cited from the wiki article itself (see below emphasis for what I am speaking to), but SELinux clearly has a means of supporting NFS at this time. I think the wording should be changed to not only fix the inaccuracy, but to make the statement generalized to the issue: AppArmor is filesystem agnostic and SELinux is not. Think 'future proofing'. Maybe show the difference in code or config?

From the article:

They also claim that AppArmor requires fewer modifications to work with existing systems: for example, SELinux requires a filesystem that supports "security labels", and thus cannot provide access control for files mounted via NFS. AppArmor is filesystem-agnostic.

While this may have been true at the time of the original writing it is not now:

4.9.3. Mounting an NFS Volume

By default, NFS mounts on the client side are labeled with a default context defined by policy for NFS volumes. In common policies, this default context uses the nfs_t type. Depending on policy configuration, services, such as Apache HTTP Server and MariaDB, may not be able to read files labeled with the nfs_t type. This may prevent file systems labeled with this type from being mounted and then read or exported by other services.

If you would like to mount an NFS volume and read or export that file system with another service, use the context option when mounting to override the nfs_t type. Use the following context option to mount NFS volumes so that they can be shared using the Apache HTTP Server:

~]# mount server:/export /local/mount/point -o context="system_u:object_r:httpd_sys_content_t:s0

108.4.240.75 (talk) 14:43, 27 May 2018 (UTC)

References

Disambiguation needed?

I was trying to find out more about this software but happened to find the Canadian company AppArmor "A division of CutCom Software Inc." Reaading their "About" it seems that they were founded in 2011 - more than 10 years after the subject of this article. Is there any connection between the two; or details of any Copyright/Trademark disputes? SlySven (talk) 15:59, 2 October 2020 (UTC)