Share AppArmor Rules!

Installed Ubuntu 10.04 a few days ago. Very impressive and I'm now using linux regularly again. I always intended to install hardened gentoo with grsecurity, pax and selinux, but apparmor is so easy to use and ubuntu much easier to install.

If you don't know what AppArmor is, take a read here: http://ubuntuforums.org/showthread.php?t=1008906. In short, AppArmor provides restrictions of the actions applications can perform, acting as a sort of sandbox and providing protection against zero day attacks.

I think one has to be careful not to blindly load a pre-built profile. For instance the streamtuner profile from the above link references audacious. I use vlc. However I also know that most folks here will never be caught out by something like that.

I think one has to be careful not to blindly load a pre-built profile. For instance the streamtuner profile from the above link references audacious. I use vlc. However I also know that most folks here will never be caught out by something like that.

Click to expand...

The beauty of apparmor profiles is that it allows total transparency so you know what you are getting, Bodhizazen is a good starting point for someone just starting out with apparmor.

Apparmor is an extra layer for itw vulnerabilities, for instance all PDF exploits via evince are blocked up apparmor, also since it doesn't use any resources or cause any slowdowns, its a good idea to have it enabled, final layer in Linux security apart from regular updates.

Question: Why do you (you = people who use apparmor) feel the need to use hardening in the first place?
Mrk

Click to expand...

I mainly use it for my browser, and consider everything else gravy. The browser is obviously the most vulnerable POI on a desktop machine, and even though there are almost no websites actively exploiting Linux browser holes, that doesn't mean there can't be in the future. The nice thing about Chromium is it has a built in sandbox already enabled, so these AA profiles might be a little superfluous (though I don't think the Chromium sandbox protects /home).

Also AppArmor is very easy to learn and is a good way to get introduced to MAC's. I typically tinker with it for the learning experience.

Well, to use a clear analogy from Windows, there's no reason for sandboxing your browser on that platform either, so there's even less need for something like that on Linux. I think the sandbox stuff is a little overrated.

Well, to use a clear analogy from Windows, there's no reason for sandboxing your browser on that platform either, so there's even less need for something like that on Linux. I think the sandbox stuff is a little overrated.

As to learning, by all means

Mrk

Click to expand...

You say this all the time but, with all due respect, you are dead wrong (especially if talking about Windows). Sandboxing is highly effective at stopping security exploits.

You say this all the time but, with all due respect, you are dead wrong (especially if talking about Windows). Sandboxing is highly effective at stopping security exploits.

Click to expand...

Correct. Especially when MAC is implemented at the kernel level, as it is with AppArmor and SELinux. Very strong, yet easy to configure. AppArmor, properly configured, proves as close to 100% security as you are going get on any platform, imo.

Any arguments that MAC is not necessary because of the unpopularity of Linux is simply security through obscurity. Just because it is not being actively exploited does not mean that it cannot be, and thus additional measures to protect your system must be taken. And who wouldn't when it is so easy to implement all the security you need through one simple solution?

Correct. Especially when MAC is implemented at the kernel level, as it is with AppArmor and SELinux. Very strong, yet easy to configure. AppArmor, properly configured, proves as close to 100% security as you are going get on any platform, imo.

Click to expand...

Nitpick: I think the GrSecurity and TrustedBSD folks would have something to say about that. Heck, even the SELinux maintainers. SELinux and whatnot aren't nearly as easy to configure, but theoretically are much stronger. And even TrustedBSD has holes in it, I've seen reports of BSD servers getting hacked and whatnot.

Nitpick: I think the GrSecurity and TrustedBSD folks would have something to say about that. Heck, even the SELinux maintainers. SELinux and whatnot aren't nearly as easy to configure, but theoretically are much stronger. And even TrustedBSD has holes in it, I've seen reports of BSD servers getting hacked and whatnot.

That being said, AppArmor is very strong by Windows standards.

Click to expand...

Not so sure about SELinux being much stronger. Much more flexible, sure. From what I understand the extra strength of SELinux is in enforcing restrictions on users, not applications - having separate classifications for objects so that they may be classified, for example, based on security clearance - top secret, classified, etc... Not sure how granularly SELinux controls IPC, but apparently AppArmor does not tightly control it. "Process activities not currently mediated by AppArmor are permitted, e.g. confined processes can perform any IPC that DAC permits, other than signals as mediated by CAP_KILL." Source: -http://kerneltrap.org/Linux/AppArmors_Security_Goals

I definitely need to spend some more time with SELinux - once I get a good least privilege configuration restricting chromium, I can compare that with my AppArmor config. That should be enlightening, and I'll post back in this thread with my findings.

With Grsecurity though, you do have a point - with ASLR and memory protection, thats a potent extra layer. I'm not sure it is in any way necessary though - even assuming a vulnerability in AppArmor or SELinux, can a single exploit really exploit a vulnerability in an application such as your web browser, and exploit a vulnerability in AppArmor/SELinux at the same time to bypass the MAC imposed? Seems highly improbable. That said, ASLR and memory protections might very well prove useful if you are intentionally executing untrusted code and relying on MAC to guard against any potentially malicious behavior.

Interesting about TrustedBSD, do you have any links to post-compromise analysis performed on those systems? I have a hard time believing MAC was remotely bypassed, if properly configured!