Exemple de sécurité SELinux réel?

11

Quelqu'un peut-il donner un exemple concret de l'endroit où SELinux a enregistré son bacon de sécurité? (ou AppArmour si vous le souhaitez). Si ce n'est pas le vôtre, un pointeur vers quelqu'un avec une expérience crédible?

Pas un test de laboratoire, pas un livre blanc, pas une bonne pratique, pas un avis du CERT, mais un vrai exemple, quelque chose comme audit2pourquoi montrer qu'une véritable tentative de piratage s'est arrêtée dans son élan?

(Si vous n'avez pas d'exemple, veuillez conserver les commentaires dans les commentaires au lieu des réponses.)

Merci!

linux security selinux

— kmarsh
source

Il y a une condition dans cette question à laquelle il est difficile de répondre. Le problème est que lorsque les systèmes ne sont pas compromis, ils ne font pas la une. Ils ne font l'actualité que lorsqu'ils sont compromis. Et donc, il y a des nouvelles sur beaucoup de systèmes CentOS compromis, qui ont été compromis exactement parce que leurs administrateurs ont désactivé SELinux parce qu'ils ne veulent pas prendre la peine d'apprendre à le configurer et à le maintenir. S'ils n'avaient pas désactivé SELinux, ils n'auraient pas été compromis.

— Juliano

Merci, mais je ne recherchais pas tant des nouvelles que des expériences personnelles réelles.

— kmarsh

5

Que diriez-vous de Russell Coker ? C'est un exemple réel car il a invité tout le monde sur sa machine en tant que root. À première vue, je pensais que c'était fou, mais ensuite vous réalisez le pouvoir de SELinux de rendre root un peu inutile.

Voici quelques exemples réels de son site.

— keithosu
source

1

Intéressant. Dans le premier lien, il donne un accès root mais (je suppose) se verrouille avec SELinux presque tout ce que root pourrait normalement faire. Bien qu'il s'agisse d'un véritable ordinateur, il ne remplit les conditions de la vie réelle que de la même manière qu'une émission de télé-réalité. Combien d'administrateurs système configureraient une machine de cette façon? Le deuxième lien est plus ce que je recherche. Je vais les regarder. Merci!

— kmarsh

4

SELinux n'est pas nécessairement une protection contre les pirates; il s'agit de documenter et d'appliquer une politique sur le comportement d'un système. C'est un outil dans la boîte à outils qui est précieux, mais nécessite des compétences pour bien utiliser.

Un exemple réel de la façon dont il vous sauve est quelque chose comme ceci:

Une vulnérabilité dans un démon FTP permet à un utilisateur anonyme d'obtenir des privilèges root. Un attaquant utilise cette vulnérabilité pour accéder aux répertoires personnels des utilisateurs et voler des clés privées SSH, dont certaines n'ont pas de phrase secrète.

Si SELinux est configuré pour interdire la stratégie "Autoriser les services ftp à lire et écrire des fichiers dans les répertoires personnels des utilisateurs", l'exploit ne réussira pas et la violation de stratégie sera enregistrée.

— duffbeer703
source

2

Ce n'est pas un exemple réel, c'est un exemple de ce à quoi pourrait ressembler un exemple réel. C'est un exemple hypothétique de la vie réelle. Ce que le PO n'a pas demandé.

— Jürgen A. Erhard

3

Voici une description détaillée d'une attaque que SELinux a stoppée dans son élan, avec des détails sur le journal et une explication des techniques médico-légales utilisées. J'ai fait publier cet article dans Linux Journal:

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

Voici un extrait du début:

Si vous exploitez des serveurs connectés à Internet, il est probable que vous deviez éventuellement faire face à une attaque réussie. L'année dernière, j'ai découvert que malgré les défenses multicouches en place sur un serveur Web de test (targetbox), un attaquant avait réussi à exploiter un exploit dans une tentative partiellement réussie d'accès. Ce serveur exécutait Red Hat Enterprise Linux 4 (RHEL 4) et le système de gestion de contenu Mambo. Il avait plusieurs défenses en place, y compris Linux sécurisé (SELinux). SELinux a empêché l'attaquant d'exécuter la deuxième étape de l'attaque, empêchant peut-être un compromis racine.

Cet article présente une étude de cas de la réponse d'intrusion, expliquant comment j'ai découvert l'intrusion, quelles mesures j'ai prises pour identifier l'exploit, comment je me suis remis de l'attaque et quelles leçons j'ai apprises concernant la sécurité du système. J'ai changé les noms de machines et les adresses IP pour des raisons de confidentialité.

— obscurerichard
source