Récemment j'ai ressenti le besoin de sécuriser un peu mon PC (et surtout l'envie d’expérimenter les divers solutions de sécurité existantes). Je ne suis pas du tout un expert dans le domaine, mais si ça intéresse quelqu'un voici ce que j'ai appris :
SELinux, AppArmor, SMAK, Tomoyo
Insuffisants. Ces solutions permettent de restreindre finement les droits des processus (plus finement qu'il n'est possible de le faire avec les permissions UNIX de base). Par exemple, comme mentionné dans un précédent commentaire, il est possible de les utiliser pour empêcher tout processus autre que firefox d’accéder aux données de ce dernier. Un malware s'exécutant sur la machine ne pourra donc pas récupérer les mots de passes stockés.
C'est bien, mais ça ne suffit pas à assurer la protection d'une machine. Le problème c'est qu'un attaquant peut essayer de contourner ces protections en attaquant directement les processus ou le noyau (SELinux, AppArmor, SMAK et Tomoyo ne font absolument rien pour empêcher ça). Les failles dans le noyau ce n'est pas si rare que ça. Si un attaquant arrive à compromettre le noyau lui même alors c'est game over, il aura absolument tout pouvoir sur la machine.
chroot
Assez compliqué à mettre en place et pas très efficace. Encore une fois, même enfermé dans un chroot, un attaquant peut toujours s'en prendre directement au noyau. Mais même sans aller jusque là, suivant les droits dont il dispose, il peut faire pas mal de bêtises. Par exemple monter un système de fichier dans le chroot, créer des devices, s'attaquer aux IPC des autres applications. Et puis, depuis le chroot il a accès à l'interface réseau localhost aussi. Ça laisse pas mal de possibilités.
Il y a des solutions plus poussées que le chroot pour isoler des processus. Je ne les ai pas testées alors je ne vais pas en parler. Mais d'après ce que j'ai pu lire à droite à gauche, il semblerait que le must de l'isolation reste la virtualisation avec Xen. Un jour il faudra que j'essaye.
grsecurity
La seule solution qui m'a convaincu jusqu'à maintenant. Grsecurity est en fait une colletions de plusieurs mécanismes de sécurité, chacun destiné à résoudre un problème précis. Il adresse le problème de la sécurité de façon plus globale que les solutions mentionnées ci-dessus.
GRSecurity inclut un certain nombre de mécanismes pour protéger le noyau lui même. Ce n'est pas absolut, mais ça rend certaines failles non exploitables (ou plus difficiles à exploiter).
GRSecurity fournit aussi RBAC, un équivalent de SELinux, AppArmor, SMAK et Tomoyo. Ce n'es qu'une opinion personnelle mais je le trouve beaucoup plus simple à utiliser. Par contre je n'ai pas obtenu de bon résultats avec le "mode apprentissage", j'ai dû faire toute ma config à la main, c'est un vrai jeu de patience. Après, rien n'empêche de désactiver RBAC et d'utiliser GRSecurity avec SELinux, AppArmor, SMAK ou Tomoyo à la place.
Enfin GRSecurity fournit PAX, une solution destinée à empêcher l'exploitation des failles de type corruption de mémoire (buffer oveflow et autres) dans les processus fonctionnant sur la machine. PAX fonctionne en rendant aléatoire la disposition des données en mémoire et en rendant certaines zone mémoire non exécutables. Le noyau Linux de base fournit déjà des mécanismes similaires, PAX ne fait que les renforcer et les compléter. De même que RBAC, PAX demande pas mal de configuration car certaines applications (firefox, python, mono…) sont incompatibles avec certains mécanismes de protections (par exemple Python a besoin que sa pile soit exécutable). Encore un jeu de patience. Il faut aussi savoir que, pour qu'un processus puisse pleinement profiter de la protection offerte par le placement aléatoire des zones mémoire, il faut qu'il est été compilé en PIE (Position Independent Executables) ce qui est loin d'être le cas de la majorité des exécutables sur la plupart des distribution (mais heureusement c'est le cas pour les plus sensibles).
Le PC depuis lequel j'écris ce post fonctionne sur une Mint 17 à laquelle j'ai ajouté GRSecurity (dans un but purement expérimental). Lors de la compilation du noyau (parce que oui pour profiter de GRSecurity il faut commencer par recompiler son noyau) j'ai pu activer presque toutes les options de sécurité. Les exceptions étant :
* GRKERNSEC_IO qui empêche X de fonctionner.
* SYSFS_RESTRICT qui fait planter le driver graphique Intel.
Il faut aussi savoir que utiliser GRSecurity signifie dire adieu à polkit (le truc graphique qui vous demande votre mot de passe lorsque vous lancez synaptic par exemple). Maintenant pour administrer ma machine je dois d'abord ouvrir un shell root puis passer en mode admin. Ça me fait trois mot de passe à retenir (utilisateur, root et admin).
En dehors de ça GRSecurity ne pose pas de problème pour une utilisation quotidienne (web, mail, chat, compilation, musique, pornvidéo, youtube, flash…). Plus tard je prévois de le tester sur une autre machine sur laquelle j'utilise les drivers proprio NVidia et Steam. Il faudra surement faire quelques ajustements pour que ça marche.
Et pour finir, il ne faut pas oublier que sous X, n'importe quel processus, peu importe les droits dont il dispose, peut voir absolument tout ce que vous tapez au clavier, et donc récupérer vos mots de passe sans soucis. Il n'existe, à ma connaissance, aucune protection contre ça. Il semble que la sécurité de Linux ai encore beaucoup ce chemin à faire.
Linus avait jeté le bébé avec l'eau du bain en disant qu'il y avait suffisamment de modules de sécurité et qu'il ne voulait pas en intégrer un nouveau.
Question de quelqu'un qui ne connaît rien au kernel : ne serait-il pas possible d'implémenter Capsicum sous forme d'un LSM (au même titre que SELinux, AppArmor, Tomoyo…) ? Après tout les LSM ont été conçus pour ça non ? Pouvoir ajouter des mécanismes de sécurité au kernel sans impacter tout le code.
# grsecurity
Posté par MadWatch . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 10.
Récemment j'ai ressenti le besoin de sécuriser un peu mon PC (et surtout l'envie d’expérimenter les divers solutions de sécurité existantes). Je ne suis pas du tout un expert dans le domaine, mais si ça intéresse quelqu'un voici ce que j'ai appris :
SELinux, AppArmor, SMAK, Tomoyo
Insuffisants. Ces solutions permettent de restreindre finement les droits des processus (plus finement qu'il n'est possible de le faire avec les permissions UNIX de base). Par exemple, comme mentionné dans un précédent commentaire, il est possible de les utiliser pour empêcher tout processus autre que firefox d’accéder aux données de ce dernier. Un malware s'exécutant sur la machine ne pourra donc pas récupérer les mots de passes stockés.
C'est bien, mais ça ne suffit pas à assurer la protection d'une machine. Le problème c'est qu'un attaquant peut essayer de contourner ces protections en attaquant directement les processus ou le noyau (SELinux, AppArmor, SMAK et Tomoyo ne font absolument rien pour empêcher ça). Les failles dans le noyau ce n'est pas si rare que ça. Si un attaquant arrive à compromettre le noyau lui même alors c'est game over, il aura absolument tout pouvoir sur la machine.
chroot
Assez compliqué à mettre en place et pas très efficace. Encore une fois, même enfermé dans un chroot, un attaquant peut toujours s'en prendre directement au noyau. Mais même sans aller jusque là, suivant les droits dont il dispose, il peut faire pas mal de bêtises. Par exemple monter un système de fichier dans le chroot, créer des devices, s'attaquer aux IPC des autres applications. Et puis, depuis le chroot il a accès à l'interface réseau localhost aussi. Ça laisse pas mal de possibilités.
Il y a des solutions plus poussées que le chroot pour isoler des processus. Je ne les ai pas testées alors je ne vais pas en parler. Mais d'après ce que j'ai pu lire à droite à gauche, il semblerait que le must de l'isolation reste la virtualisation avec Xen. Un jour il faudra que j'essaye.
grsecurity
La seule solution qui m'a convaincu jusqu'à maintenant. Grsecurity est en fait une colletions de plusieurs mécanismes de sécurité, chacun destiné à résoudre un problème précis. Il adresse le problème de la sécurité de façon plus globale que les solutions mentionnées ci-dessus.
GRSecurity inclut un certain nombre de mécanismes pour protéger le noyau lui même. Ce n'est pas absolut, mais ça rend certaines failles non exploitables (ou plus difficiles à exploiter).
GRSecurity fournit aussi RBAC, un équivalent de SELinux, AppArmor, SMAK et Tomoyo. Ce n'es qu'une opinion personnelle mais je le trouve beaucoup plus simple à utiliser. Par contre je n'ai pas obtenu de bon résultats avec le "mode apprentissage", j'ai dû faire toute ma config à la main, c'est un vrai jeu de patience. Après, rien n'empêche de désactiver RBAC et d'utiliser GRSecurity avec SELinux, AppArmor, SMAK ou Tomoyo à la place.
Enfin GRSecurity fournit PAX, une solution destinée à empêcher l'exploitation des failles de type corruption de mémoire (buffer oveflow et autres) dans les processus fonctionnant sur la machine. PAX fonctionne en rendant aléatoire la disposition des données en mémoire et en rendant certaines zone mémoire non exécutables. Le noyau Linux de base fournit déjà des mécanismes similaires, PAX ne fait que les renforcer et les compléter. De même que RBAC, PAX demande pas mal de configuration car certaines applications (firefox, python, mono…) sont incompatibles avec certains mécanismes de protections (par exemple Python a besoin que sa pile soit exécutable). Encore un jeu de patience. Il faut aussi savoir que, pour qu'un processus puisse pleinement profiter de la protection offerte par le placement aléatoire des zones mémoire, il faut qu'il est été compilé en PIE (Position Independent Executables) ce qui est loin d'être le cas de la majorité des exécutables sur la plupart des distribution (mais heureusement c'est le cas pour les plus sensibles).
Le PC depuis lequel j'écris ce post fonctionne sur une Mint 17 à laquelle j'ai ajouté GRSecurity (dans un but purement expérimental). Lors de la compilation du noyau (parce que oui pour profiter de GRSecurity il faut commencer par recompiler son noyau) j'ai pu activer presque toutes les options de sécurité. Les exceptions étant :
* GRKERNSEC_IO qui empêche X de fonctionner.
* SYSFS_RESTRICT qui fait planter le driver graphique Intel.
Il faut aussi savoir que utiliser GRSecurity signifie dire adieu à polkit (le truc graphique qui vous demande votre mot de passe lorsque vous lancez synaptic par exemple). Maintenant pour administrer ma machine je dois d'abord ouvrir un shell root puis passer en mode admin. Ça me fait trois mot de passe à retenir (utilisateur, root et admin).
En dehors de ça GRSecurity ne pose pas de problème pour une utilisation quotidienne (web, mail, chat, compilation, musique,
pornvidéo, youtube, flash…). Plus tard je prévois de le tester sur une autre machine sur laquelle j'utilise les drivers proprio NVidia et Steam. Il faudra surement faire quelques ajustements pour que ça marche.Et pour finir, il ne faut pas oublier que sous X, n'importe quel processus, peu importe les droits dont il dispose, peut voir absolument tout ce que vous tapez au clavier, et donc récupérer vos mots de passe sans soucis. Il n'existe, à ma connaissance, aucune protection contre ça. Il semble que la sécurité de Linux ai encore beaucoup ce chemin à faire.
[^] # Re: Qu'est ce qui a changé?
Posté par MadWatch . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 2.
Question de quelqu'un qui ne connaît rien au kernel : ne serait-il pas possible d'implémenter Capsicum sous forme d'un LSM (au même titre que SELinux, AppArmor, Tomoyo…) ? Après tout les LSM ont été conçus pour ça non ? Pouvoir ajouter des mécanismes de sécurité au kernel sans impacter tout le code.