Linux Kernel Security (SELinux vs AppArmor vs Grsecurity)

Linux kernel is the central component of Linux operating systems. It is responsible for managing the system’s resources, the communication between hardware and software and security. Kernel play a critical role in supporting security at higher levels. Unfortunately, stock kernel is not secured out of box. There are some important Linux kernel patches to secure your box. They differ significantly in how they are administered and how they integrate into the system. They also allow for easy control of access between processes and objects, processes and other processes, and objects and other objects. The following pros and cons list is based upon my personal experience.


Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies for Linux kernel. It is included with CentOS / RHEL / Fedora Linux, Debian / Ubuntu, Suse, Slackware and many other distributions.

SELinux features

  1. Clean separation of policy from enforcement
  2. Well-defined policy interfaces
  3. Support for applications querying the policy and enforcing access control
  4. Independent of specific policies and policy languages
  5. Independent of specific security label formats and contents
  6. Individual labels and controls for kernel objects and services
  7. Caching of access decisions for efficiency
  8. Support for policy changes
  9. Separate measures for protecting system integrity (domain-type) and data confidentiality (multilevel security)
  10. Very flexible policy
  11. Controls over process initialization and inheritance and program execution
  12. Controls over file systems, directories, files, and open file descriptors
  13. Controls over sockets, messages, and network interfaces
  14. Controls over use of “capabilities”

Pros and Cons

  • Admin skill set (learning curve) – High
  • Complex and powerful access control mechanism – Yes
  • Detailed configuration required – Yes
  • GUI tools to write / modify rules set – Yes
  • CLI tools to write / modify rules set – Yes (see list of commands here)
  • Ease of use – No (often described as horrible to use)
  • Binary package – Available for most Linux distributions
  • System performance impact: None
  • Security Framework: Mandatory access controls using Flask
  • Auditing and logging supported – Yes
  • Typical user base – Enterprise users
  • Documentation – Well documented

=> Official project website :


AppArmor (Application Armor) is another security software for Linux which maintained and released by Novell under GPL. AppArmor was created as an alternative to SELinux. AppArmor works with file paths. According to official Novell FAQ:

AppArmor is the most effective and easy-to-use Linux application security system available on the market today. AppArmor is a security framework that proactively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing good program behavior and preventing even unknown software flaws from being exploited. AppArmor security profiles completely define what system resources individual programs can access, and with what privileges. A number of default policies are included with AppArmor, and using a combination of advanced static analysis and learning-based tools, AppArmor policies for even very complex applications can be deployed successfully in a matter of hours.

AppArmor is default in OpenSUSE and Suse Enterprise Linux. It was first successfully packaged for Ubuntu Linux.


  1. Full integration.
  2. Easy deployment.
  3. AppArmor includes a full suite of console and YaST-based tools to help you develop, deploy and maintain application security policies.
  4. Protects the operating system, custom and third-party applications from both external and internal threats by enforcing appropriate application behavior.
  5. Reporting and alerting. Built-in features allow you to schedule detailed event reports and configure alerts based on user-defined events.
  6. Sub-process confinement. AppArmor allows you to define security policies for individual Perl and PHP scripts for tighter Web-server security.

Pros and Cons

  • Admin skill set (learning curve) – Medium
  • Complex and powerful access control mechanism – Yes.
  • Detailed configuration required – Yes.
  • GUI tools to write / modify rules set – Yes (yast2 and wizards).
  • CLI tools to write / modify rules set – Yes.
  • Ease of use – Yes (often described as less complex and easier for the average user to learn than SELinux).
  • Binary package – Available for Ubuntu / Suse / Opensuse and distros.
  • System performance impact – None.
  • Security Framework – Mandatory access controls.
  • Auditing and logging supported – Yes.
  • Typical user base – Enterprise users.
  • Documentation – Documented (mostly available from Opensuse and Suse enterprise Linux).

=> Official project website :


grsecurity is a set of patches for the Linux kernel with an emphasis on enhancing security. It utilizes a multi-layered detection, prevention, and containment model. It is licensed under the GPL.


  1. An intelligent and robust Role-Based Access Control (RBAC) system that can generate least privilege policies for your entire system with no configuration
  2. Change root (chroot) hardening
  3. /tmp race prevention
  4. Extensive auditing
  5. Prevention of arbitrary code execution, regardless of the technique used (stack smashing, heap corruption, etc)
  6. Prevention of arbitrary code execution in the kernel
  7. Randomization of the stack, library, and heap bases
  8. Kernel stack base randomization
  9. Protection against exploitable null-pointer dereference bugs in the kernel
  10. Reduction of the risk of sensitive information being leaked by arbitrary-read kernel bugs
  11. A restriction that allows a user to only view his/her processes
  12. Security alerts and audits that contain the IP address of the person causing the alert

Pros and Cons

  • Admin skill set (learning curve) – Low.
  • Complex and powerful access control mechanism – No (it is simpler to administer than other two implementations. Also, policies are simpler to create, since there are no roles or complicated domain/file transitions).
  • Detailed configuration required – No (works in learning mode).
  • GUI tools to write / modify rules set – No.
  • CLI tools to write / modify rules set – Yes (gradm tool).
  • Ease of use – Yes.
  • Binary package – Available for Ubuntu / RHEL / CentOS / Debian distros.
  • System performance impact – None.
  • Security Framework – Mandatory access controls (precisely, it is a RBAC implementation) using access control lists.
  • Auditing and logging supported – Yes.
  • Typical user base – Webserver and hosting companies.
  • Documentation – unfortunately, is not well documented.

=> Official project website :


All three offers very good protection and I can select them based upon the following simple criteria:

  • New user / ease of use : Grsecurity
  • Easy to understand policy and tools : AppArmor
  • Most powerful access control mechanism : SELinux
Feature SELinux AppArmor grsecurity
Automated No (audit2allow and system-config-selinux) Yes (Yast wizard) Yes (auto traning / gradm)
Powerful policy setup Yes (very complex) Yes Yes
Default and recommended integration CentOS / RedHat / Debian Suse / OpenSuse Any Linux distribution
Training and vendor support Yes (Redhat) Yes (Novell) No (community forum and lists)
Recommend for Advanced user New / advanced user New users
Feature Pathname based system does not require labelling or relabelling filesystem Attaches labels to all files, processes and objects ACLs

My personal choice is grsecurity as it is easier to use and offers many other security features. I’ve used SELinux as it is default choice under RHEL. AppArmor was only tested in lab under OpenSuse. I suggest you download and install all 3 patches (also available via binary deb and rpm files) and compare them as per your setup to gain a deeper understanding of their differences.


🐧 Get the latest tutorials on Linux, Open Source & DevOps via RSS feed or Weekly email newsletter.

🐧 23 comments so far... add one
CategoryList of Unix and Linux commands
Disk space analyzersncdu pydf
File Managementcat
FirewallAlpine Awall CentOS 8 OpenSUSE RHEL 8 Ubuntu 16.04 Ubuntu 18.04 Ubuntu 20.04
Network UtilitiesNetHogs dig host ip nmap
OpenVPNCentOS 7 CentOS 8 Debian 10 Debian 8/9 Ubuntu 18.04 Ubuntu 20.04
Package Managerapk apt
Processes Managementbg chroot cron disown fg jobs killall kill pidof pstree pwdx time
Searchinggrep whereis which
User Informationgroups id lastcomm last lid/libuser-lid logname members users whoami who w
WireGuard VPNAlpine CentOS 8 Debian 10 Firewall Ubuntu 20.04
23 comments… add one
  • Alexander Slesarev May 27, 2009 @ 23:31

    Sorry, but I want to notice that the future of the AppArmor project is not so bright. Novell lie off AppArmor programmers, including Crispin Cowan (AppArmor’s founder and leader). Crispin is now working in the Microsoft company.

    Other AppArmor’s key developers (Steve Beattie and Dominic Reynolds) wanted to organize an AppArmor consulting company called Mercenary Linux. But there are no any links to this company, and the declared site is providing an adult content now.

    Last releases of AppArmor was about a year ago, and there are not any seen movements in this direction now.

    • 🐧 nixCraft May 27, 2009 @ 23:52


      Thanks for pointing out new info.

  • Matt Summers Jun 3, 2009 @ 13:40

    Nice article. I wanted to mention that the PAX/GrSecurity patch set goes far beyond MAC in terms of hardening your system. The stack smashing protection is huge. At Gentoo we are working on a stable implementation with gcc-4.3. Results are really solid so far, a lot of progress has been made. Gentoo’s Hardened Project has some pretty good docs related to Pax/GrSec as well as SELinux, however we do not currently work with AppArmor. For any edge device or mission critical system with untrusted users Pax/GrSec is without a doubt the weapon of choice. Feel free to jump on Freenode IRC channel #gentoo-hardened if you have any questions.

  • Miker Aug 26, 2009 @ 19:11

    I think you have a mix-up in the summary table on the features line. Selinux uses labels and Apparmor uses paths correct?

  • duck Feb 18, 2010 @ 17:32

    I’m not sure about that “performance impact: none”. For example, according to Novell’s official FAQ, Apparmor’s performance impact should be around 2%…

  • duck Feb 18, 2010 @ 18:15

    Oh and says there’s minimal performance impact with Grsecurity’s NX but other features can show an impact of 3%-20%. And I’m sure SELinux is even worse…

  • anon Mar 3, 2010 @ 5:09

    selinux has 7% + overhead… some benchmarks on some tasks like network intensive show overhead of 16%. Google “selinux overhead” for plenty of links.

    yep, he mixed up the entries in his table, but apparently doesn’t care.

  • szymon_g Apr 21, 2010 @ 0:09

    nice site, but I would add some information:
    1. Apparmor- this project is dead. Novell fired AA developers in Oct 2007. OpenSUSE is prepared for shipping with SELinux (although it doesn’t have workable policies, unlike Fedora)- base programs and libraries are installed, common userland apps are patched etc.
    2. Grsecurity (incl. PaX) is much more than ‘traditional’ MAC – it also offers memory protection, ASLR etc
    3. Where is TOMOYO? it was included in 2.6.30, it offers better security (if configured properly) than AA (but less than SELinux); its really nice for use (offers ‘learning mode’, human-readable policies, works fine with updates of system /libraries etc/

  • Andrea Sep 2, 2010 @ 9:32

    there is an error in the Feature table:

    SELinux attaches labels to all files, processes and objects and not AppArmor…

  • Georgi Kolev Nov 19, 2010 @ 11:54

    Nice article 🙂
    p.s.: Slackware dosn’t include SELinux (or AppArmor / grsecurity ).

  • Doofy Jan 8, 2011 @ 12:50

    Please revise the last row in your comparison table.
    I think apparmor is path based and selinux is lable based.

  • Wannabe Jun 1, 2011 @ 13:48

    Thanks for the great comparison. I’d also like to agree with the previous posters that in the table the last row (“Feature”) has the SELinux and AppArmor fields flipped. Otherwise, nice work!

  • Dave Keays Jul 21, 2011 @ 6:18

    “Pathname based system does not require labelling or relabelling filesystem”
    I’ve only lightly played with SELinux and your comparison chart really threw a curve at me. Until I read the comments I was wondering what was wrong with my installation.

  • batou Aug 4, 2011 @ 20:28

    Bad, bad article – things are messed up. AppArmor (as now used in Ubuntu say 10.04, 10.10) is the easiest tool – but least powerful, and GrSecurity is the very strong but probably harder to start with tool – for geek admins, not for random Ubuntu user that just starts with linux.. 😉
    Also what others said – AppArmor is path based and SELinux is notable for labelling, actually SELinux probably IS the most common example of needing labeling…

  • Miro Rovis Aug 23, 2011 @ 20:29

    I vote for:
    Brad Spengler ( the author of grsecurity)
    with all due respect to NSA (and all the feds and all of their works, esp. for the Patriot Act and abolishing free speech and things, bacically… But, hey: “Change has come to America!” said Obama…)
    Anyway, was useful!
    Just, when’s you goin ta correct that typo, man?

  • Jesse Taylor Jul 11, 2012 @ 5:21

    Are there any cases where it would make sense to use more than one of these systems at the same time (e.g. SELinux + GrSecurity)? Is there any benefit to doing so?

  • elmish Mar 8, 2013 @ 8:27

    Tomoyo is great, use it!
    come in two flavors: as kernel modol (v2) or a as a kernel patch (v1).
    no need to recompile the kernel.
    I learn how to use is it in few hours and I am have medium skills in linux.

    thank you japan 🙂

  • Matthew Apr 21, 2013 @ 6:58

    want to know computers. security for it. willin to learn.root phone first then skies the limit .

  • Eduardo Apr 26, 2013 @ 18:22

    I have reading about Linux hardening and I have known grsecurity. Reading more about it, I got a doubt: Why grsecurity was not merged with Linux main tree? Anyone knows?

    • Cees Timmerman Feb 5, 2017 @ 14:48

      Linus wants security stuff as modules, because not everyone needs them nor agrees on which is best.

  • VPS Oct 25, 2014 @ 8:50

    I tried apparmor, anyone knows how others two are good with hardening.

  • Jesse Taylor Nov 30, 2015 @ 20:54

    Unfortunately the project lead for grsecurity (Brad Spengler) has declared that the stable grsecurity release will no longer be available to the public, and will only be shared with people who pay him $200 per month to become a “Commercial Support” member. He claims that this is a “solution” to the problem of companies violating GPL, but unfortunately this stupid decision means that very few people are going to be able to actually use grsecurity anymore. Hopefully the grsecurity team will come around and realize that making the project unavailable to the public is only going to make things worse … but until then, people will have to look for alternatives.

  • Cees Timmerman Feb 5, 2017 @ 14:54

    As a multi-user OS isolates users, wouldn’t it suffice to create a user for each process?

Leave a Reply

Your email address will not be published.

Use HTML <pre>...</pre> for code samples. Still have questions? Post it on our forum