Security Through Boredom

Menu

Post navigation

Creating Strong Apparmor Profiles

Recently I read a great blog post from Azimuth Security entitled Poking Holes In Apparmor Profiles. The piece highlights the issues with Apparmor profiles currently deployed and how using Ux, Px, and Cx, can lead to privilege escalation or even a complete breakout from the profile.

It’s because of the points brought up in the post that I tend to audit and recreate profiles for my specific needs. Oftentimes when I read through the profiles I see a lot of #include ‘s that are too ‘wide’ and a lot of profile authors leaving “Ux”‘s in the profile with a note saying they’ll profile it later.

Adding a Ux or Px or Cx is not the worst possible thing, your attacker isn’t suddenly in control of the system. But it gives a huge amount of room to them so you want to avoid it whenever possible. An attacker can write their payload to the disk with the initial exploited program and then use Ux to have the other program run it unconfined.

The story is mostly the same with Px and Cx but instead of full execution you just get potential privilege escalation (going from a very confined profile to a less confined one).

Apparmor can be fixed though. You can read more about that in Azimuth’s blog post because I’m too lazy to talk about it myself/ I just got back from my trip.

Let’s also keep in mind that there are other benefits to Apparmor. Initial exploits often won’t work on a program running in Apparmor because the exploit will try to read/write to some files that might allow for an information leak or give details that the attacker needs to successfully exploit the program. If you aren’t using Ux none of this even matters and, personally, I’ve made it kind of a habit to profile what I can.