Why I Like AppArmor More Than SELinux

AppArmor and SELinux are two of the Linux Security Modules that can be used for fine grained mandatory access control. They both try to accomplish very similar goals but AppArmor is widely considered to be easier to use (and, really, it is) and SELinux is widely considered to be more fine grained.

Bypassing AppArmor

AppArmor is pathbased by nature, which means that it doesn’t know what “pidgin” is it knows what “/usr/bin/pidgin” is. Because of this all AppArmor profiles deny mount and namespace access because they can obviously lead to a bypass.

AppArmor doesn’t limit IPC in any way (DAC handles it) once granted so while “pidgin” may not be able to access a file it may be able to manipulate another process into doing so.

I don’t think there’s been a remote bypass of AppArmor in ages and because AppArmor can actually prevent exploits in the first place (with proper profiles) it’s really very strong.

Bypassing SELinux

SELinux allows for an even tighter sandbox than AppArmor without the restraints of mount/ namespaces because SELinux isn’t name based.

I don’t think there are any inherent weaknesses or limitations of SELinux worth mentioning and, as with AppArmor, there hasn’t been a remote bypass in a long time.

So SELinux is also very powerful.

So What’s The Real Difference?

Often times if one is bypassable the other is. SELinux is truly the more secure option in terms of limiting a process but what comes with that is a very complex policy. An SELinux policy can be a dozen times longer than an apparmor policy and it’s definitely not as user friendly both in terms of readability and configuration. So while SELinux is ideally much more secure they both provide a really high level of security and AppArmor is way easier to apply.

In Other Words…

They’re both incredibly secure but AppArmor is far easier to audit because of the simplicity. I respect that a properly configured SELinux profile is potentially much stronger than a properly configured AppArmor profile but if I can’t audit the policy I can’t verify the policy and that’s important.

I would rather run my system with every damn thing locked under AppArmor because I’m able to write the profiles myself than run a system with a few programs under SELinux written by someone else that I can’t properly audit because the policy is just convoluted.

This isn’t “AppArmor is better than SELinux” at all. I’m not saying that SELinux is weaker or worse. I’m saying that for me, personally, I’ll take AppArmor because having an easy to use security tool feels more secure to me than having a hard to use one. And I like RBAC too but it’s outside of the scope here – I will say that RBAC is really easy to audit and set up.



AppArmor How-To

A short guide to get you started on AppArmor

AppArmor is a linux security module that allows for path based mandatory access control. It’s easy to learn and very effective at both preventing and containing exploits. I suggest you make use of it.

This post is just a short crash course to get you set up and using apparmor.

Step 1:
We first need to install the apparmor-utils package.
sudo apt-get install apparmor-utils
Once it’s done installing you should be able to access these commands:
# aa-logprof
# aa-status
# aa-autodep
# aa-enforce
# aa-complain
Step 2:
Let’s create our first profile. I’ll use pidgin.
# aa-autodep pidgin
This will create the pidign profile in complain mode. Complain mode will audit violations but not stop them.

Step 3:
Close (if open) pidgin and then open it up again. And then close it. Then run the command:
# aa-logprof

At this point you’ll be greeted with some of the “complaints” that were logged. Review and allow what’s needed.

r: r is read access
w: w is write access
a: a is limited write access (append)*
k: k allows the ability to lock a file
m: m lets a file be loaded into memory
x: allows execution
ix: executes the file under the constraints of the profile (inherit)
ux**: executes the file outside of the profile (unconfined)

Cx: executes the file in its own profile, which is specific to the parent process
Px**: executes the file in its own profile, which you will have to define (profile)

*not to be confused with allow. a is the rule, allow is a command that applies it via logprof.

**Capital C, P or U means that the environment is sanitized before executing the code. You want to sanitize whenever possible.

Step 4:

To test the profile out run:

# aa-enforce /etc/apparmor.d/usr.bin.pidgin

if it isn’t working still set it back to complain:

# aa-complain /etc/apparmor.d/usr.bin.pidgin

The first few times I set up a profile I ended up with a super convoluted mess. It was terrible. I wiped it, started over and actually *thought* before I hit “allow” or “inherit” and in very little time I was able to create many profiles for my programs.
Profiles are stored in /etc/apparmor.d/<path.path.path> so for pidgin it’s /etc/apparmor.d/usr.bin.pidgin. You can manually edit the profiles with a text editor. This is really simple and I suggest you have a look at a few profiles before you start.


1) Instead of aa-autodep you can try aa-genprof, which will try to build a partial profile for you.

2) Development profiles can be a great place to start. You can get them here:


3) Apparmor profiles can get complicated. Don’t bother trying to profile something like compiz, there’s no real point. A program like Pidgin or xchat is perfect though.

Creating Strong Profiles 

There are a few things to make note of when aiming to create very strong AppArmor profiles. Get used to everything above here so you’ve got your bearing before looking below.

1) Abstractions

Abstractions are generic templates that can be imported into AppArmor profiles. Most profiles come with at least a few abstractions. Abstractions are dangerous – they can pull in other abstractions within them, and lead to far more rights than your program may need. Creating with abstractions is easy but your profiles will be stronger without them. If you’re going to use abstractions always review what you’re pulling in.

2) Owner Tag

The “owner” tag is your friend. Sometimes you have to give a program really unruly access to your file system (/home/** rw). Using the “owner” tag means that (in the case of /home/** rw) the profiled program can only read/write to files that it has ownership of. This is a really useful tag and I suggest you make use of it wherever possible. Programs mostly just need access to their own files and folders, especially for write access, and owner is great for enforcing this.

3) Know Which Execution Rules To Use

There are four execution rules: ix, Cx, Px, and Ux. Knowing when to use them is important, but not difficult.

First of all, never use UX. Let’s remove it as an option right now.

Often times it’s easiest to just inherit the process, but oftentimes this is not the best action. Inherited processes should be the ones that will only act on files already defined.

For example, Chrome might call /bin/which to interact with its files. There’s no need to run which in a child process,  it needs access to all of Chrome’s files and nothing else.

You most certainly wouldn’t want to run Native Client as an inherited process. Native Client will require its own separate resources and rules, so it makes much more sense to run it as Px.

You may also consider running Native Client as a child process from Chrome, though in my opinion this isn’t as powerful as Px as you can not have child processes within a child process.

A child process is very good for situations where you don’t want the process to always be confined. For example Chrome needs to run xdg-settings. You don’t want xdg-settings to always be profiled, and even if you did you wouldn’t need all of those capabilities just for what chrome will use it for. So running it as a child makes the most sense.

As you create more profiles this all becomes much easier and intuitive.

4) Avoid UX, Be Wary Of PX/CX

There are three execution rules that can let an attacker gain privileges, CX, PX, and UX.

Never use UX – if you use UX you make your profile far far weaker, essentially allowing an attacker to execute any file they can write on the system. Really, if you feel the need to UX then your profile is in trouble, go for CX instead.

Attackers can potentially escalate privileges by moving to a new process under a new profile. They do this through CX/PX. If I’m an attacker in someone’s Pidgin profile but I can’t access the files I need I might hop over to the browser process through a “/usr/bin/firefox Px” rule, which would then let me access anything the Firefox profile has access to.

Always use a capital P/C. This ‘sanitizes’ the environment, which removes specific variables that could be passed along to the new process. You very rarely can’t sanitize the environment and it’s far more secure to do so.

5) Don’t Allow Writing To Areas You Can Map

Mapping a file to memory can potentially allow an attacker to move forward in an exploit, either by then marking it as executable or using ROP. If an attacker can write to an area it’s best not to allow it to be mapped. If it’s absolutely necessary make sure to restrict it with an ‘owner’ tag, at the very least. This is usually the case for cache files and sometimes /tmp. Avoiding the combination is a good idea

This isn’t all you can do. Very specific rules with file extensions are one more way to be secure. Use your imagination.


Is Ubuntu Really More Secure Than Windows 7?

Is Ubuntu Really More Secure Than Windows 7?

A lot of people look at Linux because they hear that it’s more secure, among other things. Is there truth to this? In my opinion, yes, and it’s a very complicated subject. I’m only going to touch on a few aspects of operating systems here but you should walk a way with a good idea about whether or not Linux is more secure than Windows.

Ubuntu is one of, if not the most used user-oriented Linux distros. The comparison to Windows 7 (the most widely used user Windows OS) is inevitable. While most of this applies to Linux in general I’m singling out Ubuntu specifically due to market share, userbase, and a particular feature I talk about shortly at the end.

Why Windows 7 Is Secure
I’m not going to go into why Windows XP is insecure but I’ll explain how Vista and 7 improved security. There are definitely a few significant changes that should be noted so that we can compare those changes to Linux implementations.

The first really big change in Windows 7 is ASLR and SEHOP. ASLR is Address Space Layout Randomization and it essentially makes it difficult for an attacker to use a programs own code to execute what they want. SEHOP is a technique that specifically deals with SEH overwrites ie: a specific type of overflow that targets the Structured Exception Handler. SEH overwrites made up 20% of the exploits in the Metasploit Framework at one point. These two techniques directly address highly exploitable features of the OS.

The next change is adding a Windows Update that doesn’t completely suck. XP made you go through IE, it was awful and (I don’t know about you guys) it never worked well for me. The new updater is simple, independent, and far less buggy in my experience.

And then there’s the change in Microsoft. They realized people didn’t like getting infections and they’ve made a huge shift from being insanely slow to patch to being pretty proactive about it. This newfound ability to get patches out quickly combined with an updater that isn’t completely awful is really great for users and is probably one of the largest reasons why we’ve started to see OS exploits drop and 3rd party exploits rise.

Lastly there is the under-appreciated Mandatory Integrity Access Control. Windows 7 has segregated the file system into layers primarily consisting of “Low”, “Medium”, and “High”, integrity files and folders. Programs running at low can’t write to medium/ high, programs running at medium can’t write to high, and programs running at high can write anywhere. It’s very powerful and it’s the basis of the Chrome and IE9 sandboxes.

Why Ubuntu Does It Better
I won’t go into OSS vs CSS in this post. Maybe if I get really really bored some day if anyone actually ever reads this thing. I also will not go into “security through obscurity” as it’s not actually a real thing. I’m going to focus on some other points, which are more easily substantiated.

The first real boon to Ubuntu’s security is package management. Probably my favorite part about running Linux is that I don’t have to do a thing to keep the system up to date. On Windows it’s “Run Flash Updater… ok done… run Java updater… ok done… run Windows updater… etc” but on Linux it’s all handled in one place. I click “Update” (or nothing at all, it’ll do it on its own eventually) and my browser, plugins, IM client, IRC client, and operating system (and anything else) are all patched up. Consider the significance of this – the Flashback trojan infected 700,000 OSX systems using a vulnerability that had been patched *months* before.

Where Windows has Mandatory Integrity Access Control (MIAC) Ubuntu has Apparmor. Well, sorta. Ubuntu has a set of permissions that follow DAC policies. What Ubuntu also has is a MAC implementation that allows for incredibly finely grained access control. On Windows there are very few programs that actually run at low integrity, on Linux virtually every application can run with Apparmor and there are a few that do by default – specifically system services. Apparmor is incredibly powerful because almost anyone can learn to use it – creating a profile takes minutes in most cases and it reinforces the already fair access control. MIAC can’t touch Apparmor – it’s not even close.

Ubuntu is actually fairly unique among distros as it’s one of the first to implement the new Mode 2 Seccomp Filters. A new way to limit visible kernel attack surface by only allowing syscalls on a whitelist basis. This is a new feature so it’s not easy to gauge but, judging by the principal, it should pair incredibly well with other security mechanisms like Apparmor by preventing privilege escalation.

So there you have it. Why Ubuntu is more secure than Windows 7.

What Needs To Be Said

There’s no actual way to say X is more secure than Y. I know, I just typed this whole thing out but we can only make a best guess; there is no objective measure of security. I can’t say that powerful ASLR is more important than strong malicious file detection without significant research to back that up, and even then it’s limited. What I can do is use my own judgement to take the above information (among other things) to come to a conclusion and do my best to present this to you.

There’s a lot more to all of this than what I’ve posted and there are a lot of opinions about it. This isn’t some huge research paper attempting to provide definitive answers, it’s just me, bored, comparing two operating systems. Windows 8 is entirely outside of the scope of this as it includes many new security features.

I could write a lot more like how Linux is inherently more secure because blah blah blah open source blah blah blah kernel blah blah blah but I won’t. Not tonight. Maybe some other night I’ll do an “Is Linux more secure than Windows?” blog post that goes in depth into things like ASLR implementations (mmap is randomized, virtualalloc isn’t), NX(execshield, emet), smartscreen, DAC vs MAC, etc.