SELinux, c'est bô

[gauret]

Depuis quelques jours, je joue pas mal avec SELinux, et je dois avouer que c'est carrément impressionnant.

Je comprends mieux tout le buzz qu'il y a autour.

Pour la sécurité système, je vois pas comment on pourrait faire mieux. Petite explication :

SELinux est un patch du noyau qui permet d'ajouter une couche de sécurité au système.

Une des parties principales de SELinux est un système de labels qu'on applique aux fichiers. Et ensuite on définit dans ce qu'on appelle la "policy" (politique) ce qu'un programme qui a tel label peut faire.

Exemple : je suis un maso et je veux utiliser wu-ftpd pour faire un serveur FTP. Comme je fais pas les choses à moitié, je prends une vieille version. (il faut savoir que WU-FTPd et un des premiers serveurs FTP, et est à peu près aussi troué qu'un fromage suisse. Voire plus. On a du mal à voir le fromage.)

Et bien dans SELinux, le binaire wuftpd a un label spécial, disons ftpd_t. Dans la policy, on a défini que les programmes avec le label ftpd_t ne peuvent lire que les fichiers dont le label est public_content_t, et ne peuvent écrire que dans les fichiers ou dossiers dont le label est public_content_rw_t.

Ensuite, on va labelliser avec public_content_t le dossier /var/ftp (et ses sous-dossiers), et avec public_content_rw_t le dossier /var/ftp/upload. Tout ça avec la commande chcon, qui marche comme chmod.

Que se passe-t-il ? Un user classique va se connecter, et tout va se passer comme prévu. Par contre, si un script kiddie passe dans le coin, et craque le serveur FTP, il se retrouve sur le système avec la main sur le processus wuftpd. Et bien quelquesoit l'utilisateur système qui fait tourner ce serveur, il n'aura le droit que de lire les fichiers avec le label public_content_t, et en écriture seulement pour ceux qui sont public_content_rw_t ! Un cat /etc/passwd ? Marche pas. Et ce, quelquesoit l'utilisateur qui fait tourner WU-FTPd. Oui oui, même si c'est root !

Donc en fait, que le serveur se fasse hacker ou pas, il n'aura toujours que la possibilité de faire ce pour quoi il a été prévu. Enorme, non ?

Et ça devient gigantesque quand on voit l'étendue des possibilités de SELinux. Ca va bien plus loin que l'accès aux fichiers, par exemple on peut interdire à un serveur d'ouvrir une socket sur le réseau. Exemple, apache n'est autorisé qu'à ouvrir des socket vers les ports de mysql, postgresql et ldap. Un script kiddie qui hacke votre page PHP mal codée et qui tente de se connecter à son serveur IRC (cas méga-classique), et ben ça va pas marcher

Pareil, on peut limiter les ports sur lesquels un service a le droit d'écouter. Et la touche final qui tue, c'est qu'on peut définir une liste de booléens, des interupteurs en gros, pour activer ou désactiver des parties de la policy. Une case à cocher et hop, apache a le droit de regarder dans les répertoires utilisateurs. Je décoche et c'est fini.

Alors c'est clair qu'il y a un boulot énorme pour bien définir ce qu'a le droit de faire un service ou pas, mais la plupart de ce boulot a déjà été fait. Et aujourd'hui je fais tourner ma FC 5 avec SELinux sans aucun souci.

En plus il y a maintenant des outils pour faire des modifs super simplement. Je veux que mon serveur FTP écoute sur le port 8021 ? Facile, j'ajoute 8021 à la liste des ports définis pour le FTP (une seule commande à lancer).

Bref, c'est ultra-puissant, et en plus ça commence à devenir simple. 100% rien que du bon

[theocrite]

Tu devrais essayer Rsbac plutôt

[yoda222]

(il faut savoir que WU-FTPd et un des premiers serveurs FTP, et est à peu près aussi troué qu'un fromage suisse. Voire plus. On a du mal à voir le fromage.)

Ça casse tout ton discours, ça...

Rapellons que le fromage suisse, ça n'a pas de trous... http://fr.wikipedia.org/wiki/Gruyère

Non mais, je parie que tu es aussi du genre à penser que mes compatriotes (je ne suis pas suisse) mangent des moules, des frites et boivent de la bière... Ah, tiens, ça, c'est vrai.

Sinon, SELinux, c'est pas mal, mais tu dit que ça protège des failles des logiciels... et si SELinux à une faille ? C'est toujours le même problème, c'est le logiciel censé éviter les choses illégales qui doit être protégé. Enfin, tu me diras que ça rajoutte une couche, et donc que c'est toujours mieux, et tu as certainement raison. M'enfin, pour un utilisateur final "normal", ça ne doit pas être très facile ;-)

[zoto]

Salut

J'en avais entendu parlé depuis un paquet de temps,

En fait c'est la NSA qui a dev ça et l'a mis en GPL .

Je crois que d'en avoir entendu parlé un peu plus ça va me stimuler pour l'etudier :) .

a+

[gauret]

Sinon, SELinux, c'est pas mal, mais tu dit que ça protège des failles des logiciels... et si SELinux à une faille ? C'est toujours le même problème, c'est le logiciel censé éviter les choses illégales qui doit être protégé.

Ouais, enfin c'est quand même plus facile de vérifier que SELinux n'a pas de faille que d'auditer tous les scripts PHP pourris du net...

Et la policy par défaut est déjà très bien faite, pas besoin d'y toucher. Sauf si tu veux faire des choses exotiques (avoir apache qui écoute sur le port 81). Mais si tu fais ça, t'es déjà plus un user de base, donc tu peux bien taper une ligne de commande...

[Guys]

Tu devrais essayer Rsbac plutôt

Tu aimes bien lancer des petits pics trolliens quand même !!!

Je suis d'accord avec toi Gauret, que c'est largement plus facile de gérer la sécurité à partir d'une entité plutôt que sur toutes les pages de codes existantes sur ta machine, c'est quand même un sacré boulot en moins ...

[shark_atlantis]

C'est toujours mieux que de crypter ces données (faut être parano aussi )

[tuXXX]

Tu devrais essayer Rsbac plutôt

Et grsec

[Guys]

Tu devrais essayer Rsbac plutôt

Et grsec

[theocrite]

C'est toujours mieux que de crypter ces données (faut être parano aussi )

Chiffrer

Et grsec

Rsbac + grsec + encfs

Juste pour info, OpenBSD permet de base de faire ça selon les securitylevels et les flags sappnd, schg et uappnd, mais ce n'est pas aussi fin, c'est pas pour toute une appli, mais tout le système.

[tsubasaleguedin]

Si on overflow ton ftp et qu'on fait un spawn de shell + escalation de privilege le systeme de label ne doit pas etre plus secure qu'un systeme classique ...

[gregoryvon]

Ça casse tout ton discours, ça...

Rapellons que le fromage suisse, ça n'a pas de trous... http://fr.wikipedia.org/wiki/Gruyère

Non non non et non, le fromage suisse ne se resume pas au gruyere, le fromage suisse avec des trous c'est l'emmental

http://fr.wikipedia.org/wiki/Emmental

vous le belge alors...

pour SElinux c'est vrai que ca à l'air sympa

[gauret]

Si on overflow ton ftp et qu'on fait un spawn de shell + escalation de privilege le systeme de label ne doit pas etre plus secure qu'un systeme classique ...

Si si, puisque ton shell se retrouvera sous le même label que le serveur FTP. Donc même si il escalade ses privilèges et choppe les droits de root, SELinux ne lui autorisera pas plus de choses que le serveur FTP. Justement c'est ça le but, c'est une protection qui vient au-dessus des droits classiques. Pas mal non ?

Sinon RSBAC c'est pas mal non plus, mais c'est pas vraiment un troll puisque les deux collaborent ;o)

Et GrSec ça fait pas la même chose.

Dans SELinux il y a aussi un système appelé MCL qui ressemble aux ACL des systèmes de fichiers : tu définis des labels pour tes users, type Marketing, Finance, Tech, etc... et tu définis des labels sur tes ressources, ex sur tes fichiers de compta tu y colle Finance. Et les users qui n'ont pas tous les labels voulus pour accéder au fichier se retrouvent bloqués.

Avantage par rapport aux ACL bêtes et méchantes : tu peux appliquer ça sur autre chose que des fichiers, exemple l'utilisation de ports réseaux, sockets, etc...

Ca c'est tout neuf, donc c'est pas intégré dans interfaces graphiques, mais bon l'infrastructure est en place et on a des outils en ligne de commande.

Mais c'est l'aspect principal, que j'ai vaguement décrit dans le premier post, que je trouve le plus intéressant. En tant que packageur, y'a plein de boulot à faire pour blinder à mort la distrib :)

[tuxbubling]

Et GrSec ça fait pas la même chose.

Sisi mais il te faut créer tes polices RBAC avec l'outil 'Gradm'. Gradm, a même une création automatique "intélligente" des polices RBAC selon l'utilisation du système

(Ca reste quand meme un peu plus limité que RSBAC)