Question: Can anyone give a real life example of where SELinux saved their security bacon? (or AppArmour if you wish). If not your own, a pointer to someone with a credible experience?

Not a lab test, not a white paper, not a best practice, not a CERT advisory, but a real example, something like audit2why showing a real hacking attempt stopped in its tracks?

(If you have no example, please keep commentary in comments instead of Answers.)

Thanks!

Answer: 
SELinux isn't necessarily about protection from hackers; it's about documenting and enforcing policy for how a system behaves. It's a tool in the toolbox that is valuable, but requires skill to use well.

A real life example of how it saves you is something like this:

> 
> A vulnerability in an FTP daemon
>  allows an anonymous user to gain root
>  privileges. An attacker uses that
>  vulnerability to access user home
>  directories and steal SSH private
>  keys, some of which do not have a
>  passphrase.
> 
> 
> 

---

If SELinux is configured to disallow the "Allow ftp services to read and write files in user home directories" policy, the exploit would not be successful, and the policy violation would be logged.
Here's a detailed write-up of an attack that SELinux stopped in its tracks, with log details and an explanation of the forensic techniques used. I got this article published in Linux Journal:

<http://www.linuxjournal.com/article/9176>

Here's an excerpt from the beginning:

> 
> If you operate Internet-connected servers, chances are you eventually will have to deal with a successful attack. Last year, I discovered that despite the multilayered defenses in place on a test Web server (targetbox), an attacker had managed to use an exploit in a partially successful attempt to gain access. This server was running Red Hat Enterprise Linux 4 (RHEL 4) and the Mambo content management system. It had multiple defenses in place, including Security-Enhanced Linux (SELinux). SELinux prevented the attacker from executing the second stage of the attack, possibly preventing a root compromise.
> 
> 
> This article presents a case study of the intrusion response, explaining how I discovered the intrusion, what steps I took to identify the exploit, how I recovered from the attack and what lessons I learned regarding system security. I've changed machine names and IP addresses for privacy reasons.
> 
> 
>