Editing Security-Enhanced Linux (section)

==Comparison with AppArmor==
SELinux represents one of several possible approaches to the problem of restricting the actions that installed software can take. Another popular alternative is called [[AppArmor]] and is available on [[SUSE Linux Enterprise Server]] (SLES), [[openSUSE]], and [[List of Linux distributions#Debian-based|Debian-based]] platforms. AppArmor was developed as a component to the now-defunct [[Immunix|Immunix Linux]] platform. Because AppArmor and SELinux differ radically from one another, they form distinct alternatives for software control. Whereas SELinux re-invents certain concepts to provide access to a more expressive set of policy choices, AppArmor was designed to be simple by extending the same administrative semantics used for [[Discretionary Access Control|DAC]] up to the mandatory access control level.

There are several key differences:
* One important difference is that AppArmor identifies file system objects by path name instead of inode. This means that, for example, a file that is inaccessible may become accessible under AppArmor when a hard link is created to it, while SELinux would deny access through the newly created hard link.
** As a result, AppArmor can be said not to be a [[type enforcement]] system, as files are not assigned a type; instead, they are merely referenced in a configuration file.
* SELinux and AppArmor also differ significantly in how they are administered and how they integrate into the system.<ref>{{cite web |url= https://www.suse.com/documentation/sles11/book_security/data/sect1_chapter_book_security.html |publisher= SUSE |series= Security Guide |work= SELinux |title= SELinux backgrounds |access-date= 8 June 2016 |archive-date= 1 July 2016 |archive-url= https://web.archive.org/web/20160701143049/https://www.suse.com/documentation/sles11/book_security/data/sect1_chapter_book_security.html |url-status= live }}</ref>
* Since it endeavors to recreate traditional DAC controls with MAC-level enforcement, AppArmor's set of operations is also considerably smaller than those available under most SELinux implementations. For example, AppArmor's set of operations consist of: read, write, append, execute, lock, and link.<ref>{{cite web | url=http://manpages.ubuntu.com/manpages/hardy/man5/apparmor.d.5.html | title=apparmor.d - syntax of security profiles for AppArmor | url-status=dead | archive-url=https://web.archive.org/web/20131017094320/http://manpages.ubuntu.com/manpages/hardy/man5/apparmor.d.5.html | archive-date=2013-10-17 }}</ref> Most SELinux implementations will support numbers of operations orders of magnitude more than that. For example, SELinux will usually support those same permissions, but also includes controls for mknod, binding to network sockets, implicit use of POSIX capabilities, loading and unloading kernel modules, various means of accessing shared memory, etc.
* There are no controls in AppArmor for categorically bounding POSIX capabilities. Since the current implementation of capabilities contains no notion of a subject for the operation (only the actor and the operation) it is usually the job of the MAC layer to prevent privileged operations on files outside the actor's enforced realm of control (i.e. "Sandbox"). AppArmor can prevent its own policy from being altered, and prevent file systems from being mounted/unmounted, but does nothing to prevent users from stepping outside their approved realms of control.
** For example, it may be deemed beneficial for help desk employees to change ownership or permissions on certain files even if they don't own them (for example, on a departmental file share). The administrator does not want to give the user(s) root access on the box so they give them <code>CAP_FOWNER</code> or <code>CAP_DAC_OVERRIDE</code>. Under SELinux the administrator (or platform vendor) can configure SELinux to deny all capabilities to otherwise unconfined users, then create confined domains for the employee to be able to transition into after logging in, one that can exercise those capabilities, but only upon files of the appropriate type.{{Citation needed|date=April 2017}}
* There is no notion of multilevel security with AppArmor, thus there is no hard [[Bell–LaPadula model|BLP]] or [[Biba Model|Biba]] enforcement available.{{Citation needed|date=April 2017}}.
* AppArmor configuration is done using solely regular flat files. SELinux (by default in most implementations) uses a combination of flat files (used by administrators and developers to write human readable policy before it's compiled) and extended attributes.
* SELinux supports the concept of a "remote policy server" (configurable via /etc/selinux/semanage.conf) as an alternative source for policy configuration. Central management of AppArmor is usually complicated considerably since administrators must decide between configuration deployment tools being run as root (to allow policy updates) or configured manually on each server.