Pour FC2 et FC3 j'ai suivit de loins SeLinux. Pour FC3 ma bécane avait SeLinux désactivé (je ne sais plus pourquoi, sûrement car j'avais la flemme d'apprendre SeLinux). Pour FC5 et FC6 (je n'ai pas utilisé FC4) j'avais SeLinux activé. Ça marchait et basta (quoique j'ai bidouillé un ou deux trucs à l'arrache pour le driver mga_vid).
J'ai installé F8 il y a peu (j'ai sauté F7), toujours avec SeLinux activé. Hier j'ai voulu installer Bugzilla et j'ai eu des soucis. Le "gardien" SeLinux empêchait la bonne exécution de Bugzilla.
Je n'ai jamais été scandalisé par ceux qui désactivent SeLinux car ils ont quelques soucis et ne veulent pas se prendre la tête avec SeLinux. Après tout Linux est un système à la base assez sûr pour ne pas dire très sûr. Enfin plein de distributions tournent sans SeLinux sans qu'on est la moindre preuve que c'est un risque "énorme" pour la majorité des usages de Linux.
Bugzilla ne marchait pas avec SeLinux mais j'avais envis de garder SeLinux activé. Plus pour le principe que par crainte d'un vilain craker. Donc je me suis plonger dans SeLinux. Plongeon en surface :-). Plongeon en surface car je ne veux pas être un spécialiste Selinux (je n'ai pas que ça à foutre :-)).
Premier défit, se documenter.
Ceci est ma plus grosse critique de SeLinux. La doc est dispersée dans tous les coins. Certaines parlent du modèle de sécurité bidule, d'autres du modèle machin, etc. Il est très dure de trouver une doc d'introduction à SeLinux satisfaisante. Pas une doc qui rendre dans l'usage des commandes par exemple, mais une donc qui permet de bien assimiler les principes de SeLinux. C'est soit sans intérêt, soit intéressant mais trop condensé (on se prend tout dans la gueule en même temps).
Le mieux que j'ai trouvé, est la doc RHEL 5.1 (la doc de RHEL 5 n'a pratiquement rien sur SeLinux !) :
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/(...)
C'est correct, sans plus.
Notez le niveau élevé de fonctionnalité demandé pour les secteurs type militaire !
C'est une doc seulement correcte de SeLinux, mais ça a été un point de départ qui m'a bien aidé. Correcte, mais je n'ai pas vu mieux :-). Donc probablement plus que correcte.
Je ne vais pas entrer dans les détail de SeLinux. Je ne suis pas un spécialiste de SeLinux et je ne cherche pas à le devenir. SeLinux est compliqué. La sécurité de façon général est compliquée. Le succès globale de toute solution de sécurité dépend aussi de la facilité à l'appliquer. Je dis bien appliquer et non implémenter. Il n'est pas question ici de développer des règles SeLinux aux petits oignons. On est dans le cadre d'un utilisateur lambda, pas d'un développeur SeLinux. On veux seulement se sortir de situations bloquantes sans "bêtement" désactiver SeLinux, sans perdre tout les bénéfices d'avoir SeLinux activé. Si un système de sécurité est trop compliqué pour être *appliqué*, aussi puissant soit le système, il sera globalement un échec car personne ne va l'utiliser.
Je vais montrer dans les grandes lignes comment répondre au problème le plus classique de SeLinux. Le cas où SeLinux interdit de faire quelque chose alors qu'ou veut que ça soit autorisé (pour faire tourner le programme X ou Y). Évidemment, on se refuse que la réponse à ce problème soit de désactiver SeLinux.
J'ai voulu installer le paquet Bugzilla livré avec F8. selinux-policy-targeted fournit déjà un support. Mais il doit y avoir un bug. Quoiqu'il en soit, on ne va pas attendre que le bug soit corrigé. Ni désactiver SeLinux en attendant que le bug soit corrigé.
Lorsque SeLinux est activé tous les refus de SeLinux sont stockés dans /var/log/audit/audit.log. Il y a des utilitaires sympa pour "enrober" tout ça, mais je les passe sous silence.
Donc il suffit de faire tourner Bugzilla et de collecter les refus relatifs à bugzilla dans un fichier. Par exemple bugzilla_avc.txt.
Avec cette collection de refus, on va créer des règles SeLinux qui vont inhiber ces refus.
# cat bugzilla_avc.txt | audit2allow -v -M bugzilla
Audit2allow va créer un module SeLinux nommé bugzilla. Module qui va autoriser ce qui a été refusé à Bugzilla. Audit2allow crée deux fichiers. bugzilla.te : version texte lisible. bugzilla.pp version compilée pour SeLinux.
Voilà à titre d'info le bugzilla.te qui a été créé chez moi pour que Bugzilla fonctionne avec SeLinux activé :
module bugzilla 1.0;
require {
type postgresql_port_t;
type net_conf_t;
type httpd_bugzilla_script_t;
type tmp_t;
type http_port_t;
class tcp_socket { name_connect setopt read create ioctl write getattr connect getopt };
class dir { write remove_name getattr search add_name };
class udp_socket { write read create connect getattr };
class file { write getattr read create unlink ioctl };
}
allow httpd_bugzilla_script_t http_port_t:tcp_socket name_connect;
allow httpd_bugzilla_script_t net_conf_t:file { read getattr };
allow httpd_bugzilla_script_t postgresql_port_t:tcp_socket name_connect;
allow httpd_bugzilla_script_t self:tcp_socket { setopt read create getattr write ioctl connect getopt };
allow httpd_bugzilla_script_t self:udp_socket { write read create connect getattr };
allow httpd_bugzilla_script_t tmp_t:dir { write remove_name getattr search add_name };
allow httpd_bugzilla_script_t tmp_t:file { write getattr read create unlink ioctl };
C'est relavitement claire. Et on n'autorise que ce qui a été refusé. Un spécialise sécurité ou Bugzilla ferait mieux. Par exemple en refusant toujours certaines actions qui ne sont pas indispensables à Bugzilla. Mais on est "seulement" un utilisateur lambda qui veut se débarasser d'un problème. Le fichier bugzilla_avc.txt sera plus "précis" (il donne les répertoires ou fichiers par exemple et non seulement les domaine). Mais oublions ces détails.
Le module créé, n'est pas actif. Pour l'activer c'est simple :
# semodule -i bugzilla.pp
C'est assez long (10 ou 20 secondes). Une grosse partie est faite en python.
Et voilà :-)
Évidemment celui qui voudra faire ça devra faire quelques man, etc... Mais c'est à la portée de beaucoup. Ça m'a pris une demi-journée. Ça a été le seul momemt que j'ai consacré à SeLinux alors que mes bécane ont SeLinux activé depuis 2 ans en gros.
On peut déjà entre voir des possibilités d'"apprentissage". Mais généraliser l'"apprentissage n'est pas un bonne solution (j'en parle plus loins).
Notez bien que ceci peut être fait sans désactiver SeLinux ni le passer en mode permissif !
Si on n'est pas on mode permissif, il peut être nécessaire (et c'est très probable) de réitérer les opérations précédentes (en complétant bugzilla_avc.txt) jusqu'à ce que SeLinux ne dise plus rien. Ça peut être assez long, mais ça marche. C'est le prix à payer pour ne pas "baisser la garde" (c-à-d passer SeLinux en mode permissif).
On a réglé notre problème bloquant, mais d'un point de vu global ce n'est pas satisfaisant. Ça ne va pas rendre Linux (le système d'exploitation installé sur des millions de bécane) plus sûr. Si tout le monde ne fait que ça, autant virer SeLinux. On comprend ici pourquoi je suis contre la généralisation de l'"apprentissage".
Mais c'est là qu'il faut garder à l'esprit comment sont développer les "vraies" règles SeLinux ("vraies" en opposition aux règles qu'on vient de créer à l'arraché). Les "vraies" règles sont celles fournies par SeLinux (NSA) ou Red Hat/Fedora, ou autres mais des spécialistes en sécurité.
Donc une fois mon problème bloquant réglé, j'ai fait un rapport de bug sur le paquet selinux-policy-targeted. J'y ai joint bugzilla_avc.txt (et bugzilla.te, mais il peut être généré depuis bugzilla_avc.txt donc c'est sans grand intérêt). Maintenant des spécialistes sécurités vont analyser le problème, peut-être contecter les développeurs de Bugzilla s'ils voient des choses étranges et une prochaine version de selinux-policy-targeted prendra en charge sans accro Bugzilla. Et nous on va pouvoir se débarraser de notre module de misère qu'on a créé "à l'arrache" (on vire le module avec semodule --remove=bugzilla).
Il faut bien retenir ici, que ce n'est pas aux développeurs de Bugzilla de créer des "vraies" règles SeLinux. Ni à nous (pauvre utilisateur lambda ou administrateur qui n'a pas que ça à foutre). Mais aux spécialistes sécurité/selinux. Donc la complexité du coeur de SeLinux nous concerne peu (on l'a vu) et elle concerne peu les développeurs. C'est l'affaire de spécialistes. On a ainsi le bon outil pour répondre aux problèmes de sécurité (par exemple SeLinux :-)). Par un outil qui a été dégradé afin facilité la vie des apprenties sécurités.
J'ai titré le journal "Le nouveau SeLinux".
Alors il y a quoi de nouveau par rapport à l'époque de FC2/FC3.
Il y a les booléens. On peut les voir/utiliser avec getsebool/setsebool ou avec system-config-selinux (interface graphique).
Par exemple le booléen httpd_use_nfs (permet à apache de lire écrire sur une partition NFS). Le booléen allow_mplayer_execstack pour que mplayer puisse utiliser certains codec mal codés ou pour charger des dll windows.
Pour F8 il y en a 112. Ils sont classés dans une quinzaine de catégorie (Samba, httpd, ftp, etc). Le paquet selinux-policy à entre autre la doc relative à ces booléens.
Dans les nouveautés, Il y a les modules. Ça permet de changer la configuration de SeLinux à la volée sans tout casser et facilement. Ça permettra aussi de fournir des régles de sécurités très spécifiques qui ne seront pas développées par la NSA par exemple. Règles dédiées à une applie et règles qui pourront être auditées par des spécialites afin de vérifier si tout et n'importe n'est pas autorisé.
Il y a des outils (dont certains graphiques) pour faciliter la vie des utilisateurs. On l'a vu dans ce journal.
Il y a les règles "targeted" de Fedora qui ne sont plus targeted mais bien aujourd'hui des règles strict (Fedora ne fournit plus selinux-policy-strict). D'ailleurs, contrairement au début de selinux-policy-targeted, il n'est plus possible de désactiver SeLinux pour un service. C'est-à-dire que Fedora a débuté avec un jeux de règles qui concernait un nombre limité de service (apache, etc) et qu'on pouvait désactiver car elles étaient peu souples (pas de booléen par exemple), à des règles qui maintenant contrôlent une bonne partie du système (jusqu'à des applis utilisateur, firefox ou mplayer par exemple). Contrôle qui comme on l'a vu peut-être inhibé très localement si c'est nécessaire (pour un besoin particulier ou à cause d'un bug dans les règles).
Enfin SeLinux peut maintenant circuler sur le réseau. Par exemple le boss sera dans la catégorie boss_t et il y a que lui qui pourra se connecter à ftp://ftp.topsecret.com/ .
Et encore plein d'autres choses.
L'avenir de Selinux ?
Je crois que SeLinux a maintenant un bon niveau de maturité et est définitivement sortit du laboratoire. C'est le top de la sécurité actuellement. Les choses vont être paufinées, son usage sera plus accessible (via des applis graphiques par exemple) sans faire le moindre compromis sur la sécurité. Je pense que petit à petit d'autres distributions vont y venir. Ça ne sera pas rapide.
Ici je pourrais glissé sur LSM qui complique grandement le développement de SeLinux (en fait de tout le monde) et AppArmor qui impose LSM car AppArmor est populaire. Mais je vais éviter. Zut, trop tard.
En passant, un document très honnète sur les fonctionnalité de AppArmor, c'est écrit par AppArmor ! :
http://kerneltrap.org/Linux/AppArmors_Security_Goals
C'est surtout Novell qui dit n'importe quoi et surtout lorsque Novell fait une comparaison de AppArmor avec SeLinux. M'enfin, je parie que Novell (peut-être pas OpenSuse) va revenir à SeLinux.
# Petite précision
Posté par IsNotGood . Évalué à 2.
# LSM
Posté par patrick_g (site web personnel) . Évalué à 9.
Ah bon c'est AppArmor qui "impose" LSM ? Et comment il fait pour l'imposer ? Il met un pistolet sur la tempe de Linus Torvalds ?
La vérité c'est qu'il n'y a pas du tout de consensus sur la sécurité et que Linus garde LSM en mainline pour permettre a toutes les solutions de fonctionner. C'est au choix de l'utilisateur.
Bien entendu il y a de la propagande a tous les étages.
Il y a ceux (SeLinux) qui disent : "Je suis le seul vrai module de sécurité alors pas besoin de LSM".
Il y a ceux (AppArmor ou Tomoyo) qui disent : "SeLinux n'est pas le seul bon module, il y a aussi nous et donc il faut garder LSM pour assurer la coexistence de tout le monde".
Enfin il y a ceux (Grsecurity) qui disent : "LSM n'est pas assez puissant pour nous. Si vous voulez la vraie sécurité sans compromis alors choisissez-nous sans passer par LSM".
Bref c'est le bordel et Linus a tranché quand il a été question de virer LSM pour ne garder que SeLinux en mainline :
"Hell f*cking NO!
You security people are insane. I'm tired of this "only my version is correct" crap. The whole and only point of LSM was to get away from that.
And anybody who claims that there is "consensus" on SELinux is just in denial.
LSM stays in. No ifs, buts, maybes or anything else.
When I see the security people making sane arguments and agreeing on something, that will change. Quite frankly, I expect hell to freeze over before that happens, and pigs will be nesting in trees. But hey, I can hope.".
Clair non ?
[^] # Re: LSM
Posté par IsNotGood . Évalué à 4.
Évidemment que non. Mais s'il n'y avait pas AppArmor, il n'y aurait probablement pas aujourd'hui LSM. Linus envisageait de virer LSM vers 2005 si j'ai bonne mémoire.
M'enfin, constatons qu'il y a AppArmor et voilà. On ne va pas aligner les développeurs d'AppArmor face et un mur etc. Évidemment que non.
Autre problème avec AppArmor, et en fait plus avec ceux qui détestent SeLinux et supportent le "cette solution simpliste devrait suffire", c'est la confusion que ça a mis dans ce qui est perçu comme la communauté des experts sécurités de Linux. Un beau bordel avec des arguments à la con (même Linus qui ne veut pas se méler de questions de sécurité c'est énervé). Ce qui est perçu comme la communauté des spécialités sécurités Linux a maintenant plusieurs discours qui sont incompatibles. La crédibilité en prend un gros coup. Et ça c'est arrivé avec AppArmor. Tu peux dire que c'est un hazard, mais je n'y crois pas. Tu peux aussi dire qu'avant tout le monde n'était pas d'accord, mais à 90 % ils étaient d'accord sur les grands principes.
Maintenant il y a les pro label et ceux qui dise que ça sert rien, c'est compliqué et blabla. Les pro pathname et ceux qui disent que c'est pourri au niveau conception. Les pro "ça devrait suffir" et les pro "il faut être rigoureux avec les sécurités". Etc. Un beau bordel.
> La vérité c'est qu'il n'y a pas du tout de consensus sur la sécurité
Comment tu entends ça ?
Au niveau NSA, DOG (armé américhaine), certains grandes comptes, administrations, etc et les spécialistes qui sont largement reconnus, il y a consensus. Et le concensus est (pour faire court) : Le principe adopté par AppArmor "sucks". Il n'y aurait pas SeLinux, alors mieux vaux AppArmor que rien (pour faire court). Et le gros de l'affaire tourne ici. Des gens ne veulent pas SeLinux (souvent avec des arguments vaseux), donc pour eux au niveau sécurité c'est AppArmor ou rien. Donc ils défendent AppArmor "à mort".
Il n'y a pas concensus dans la communauté Linux. Mais chez les personnes qui ont une forte crédibilité au niveau sécurité il y a consensus.
> Linus garde LSM en mainline pour permettre a toutes les solutions de fonctionner.
Linus botte en touche.
Sur les trucs de sécurité ce n'est pas la première fois.
http://marc.info/?l=git-commits-head&m=115954981329305&a(...)
Il avait accèpté du n'importe quoi, puis il l'a viré. Il peut très bien accèpter AppArmor (et ça va probablement arriver) et le virer dans quelques mois si le vent change de direction. NB : Linus n'est pas comme ça pour tout.
M'enfin, je le comprend. C'est le leader d'un projet avec une vaste communauté. Notons bien ce qu'a dit Linus lorsqu'on le lit "entre les lignes" :
- Il ne prétend pas être un spécialiste sécurité et ne veut pas l'être. Donc il ne veut pas prendre de lui seul la responsabilité de virer LSM.
- Il trouve que beaucoup d'arguments autours de la sécurité ces derniers temps sont du n'importe quoi (crap).
- Il constate qu'il n'y a pas consensus pour virer LSM.
Donc Linus garde LSM mais sans grande motivation. Seulement pour des raisons de "confort" car il ne veut pas prendre de décision et espère ainsi faire plaisir à tout le monde. Il changerait d'avis assez vite que ça ne m'étonnerait pas.
> Bien entendu il y a de la propagande a tous les étages.
Oui et non, voir ce que j'ai déjà écrit. Mais clairement il y propagande dans Linux et Linus la subit même s'il ne le veut pas.
Notons bien que c'est Novell qui a principalement initialisé/participé à ce bordel afin de se démarquer de Red Hat en poussant AppArmor. Mais maintenant Novell abandonne AppArmor. Novell a virer 5 développeurs d'AppArmor je crois et il doit n'en rester qu'un. Crois-tu qu'une grosse administration qui doit gérer des données sensibles va le faire avec une solution Novell/AppArmor alors que Novell n'a qu'un developpeur pour faire le support ? Ce n'est pas sérieux. On voit déjà Novell faire moins de FUD sur SeLinux (j'en est pas vu depuis longtemps). Ils prépareraient leur retour à SeLinux que ça ne m'étonnerait pas. Continuer sur AppArmor interdirait à Novell tout ce qui est armé américaine, administrations sensibles, etc...
> Il y a ceux (SeLinux) qui disent : "Je suis le seul vrai module de sécurité alors pas besoin de LSM".
C'est un peu plus compliqué. Tu simplifies le discours voire le fausse. Il y avait un excellent article sur lwn.net, mais je n'arrive pas à le retrouver. Article écrit par James Morris (gros figure de SeLinux).
Le but de virer LSM, n'est pas de virer les concurrents. C'est une conséquence. Le problème est que LSM sucks et suckera toujours. C'est aussi des points d'entrés que des modules proprios peuvent utiliser pour faire n'importe quoi.
Se trainer LSM pose des problèmes à tous les développeurs (et pas seulement aux développeurs de SeLinux ou de modules de sécurité).
Se trainer LSM pose de gros problème quand il faut faire évoluer l'API (il faut l'accord de tous ceux qui utilisent LSM).
Avoir plusieurs solutions pour la sécurité disperce les efforts. Par exemple il n'y a qu'une pile tcp/ip dans Linux. C'est un problème ? Non. Et s'il y avait plusieurs piles tcp/ip, la pile tcp/ip de Linux n'aurait pas atteind le formidable niveau qu'elle a actuellement. Il n'y a qu'un scheduler. C'est un problème ? Non. Il n'y a qu'un gestionnaire de la VM. C'est un problème ? Non. Etc.
N'avoir qu'une solution pour l'infrastructure sécurité de Linux, pourrait donner un gros coup de boost à cette dernière et donc aussi à Linux. Évidemment cette solution doit permettre les trucs archis compliqués et les trucs simples.
J'image que tu va rétorquer qu'il y a plusieurs FS. Mais c'est car il y a différents besoins techniques. Ramfs ou ext3 ou NFS ce n'est pas la même chose, ça répond à différents besoins techniques (et pas philosophique). Aucun FS n'a comme philosophie "on préfère faire simple pour l'utilisateur même si c'est au risque de perdre ses données".
Je ne suis pas un spécialiste sécurité. SeLinux est compliqué. Mais j'ai des oreille et j'écoute. J'ai des yeux et je regarde ce qui se fait.
Les oreilles ont entendu du côté de SeLinux à ses débuts et jusqu'à peu :
- "Ne cherchons pas à faire simple, faisons juste. La simplicité (ou l'accessibilité) sera faite par des applis et/ou règles qui utiliseront SeLinux"
Les yeux voient aujourd'hui que c'est le cas (du moins c'est un bon début). Par exemple pour faire des règles SeLinux voilà une petite applis (c'est un module de system-config-selinux) :
http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guid(...)
Les applications qui utilisent Selinux permettront (voire le permettent déjà) de faire aussi simple qu'AppArmor pour l'utilisateur mais sans se baser sur un principe qui sucks sur une architecture qui sucks.
Au exemple :
http://seedit.sourceforge.net/
NB : Ça utilise un modèle de sécurité moins puissant/souple que celui de la NSA/Red Hat.
SeLinux devrait être la base de la sécurité de Linux. Pas le "tout". S'il n'y avait que SeLinux, il y aurait par exemple concurrence entre Fedora et Ubuntu dans l'utilisation de SeLinux. L'un cherchant à être complet et utilisable par les clients qui exigent un controle du "workflow" et/ou des attributs de sécurité qui passent de bécanes en bécanes, etc. L'autre serait moins puissant en terme de configuration mais plus facile à assimiler. Il pourrait y avoir une concurrence plus frontale entre Mandriva avec seedit et Ubuntu.
SeLinux ce n'est pas l'uniformité.
> Clair non ?
Et alors ?
T'as trouvé un coup de sang de Linus.
Linus ne voulait pas entendre parler de la GPL v3 il y a quelques mois. Maintenant il dit "pourquoi pas".
Et regardons les forces en présence puisque sur le dossier sécurité c'est actuellement plus le lobbying qui compte que les arguments techniques (J'ai presque envis d'ajouter "dexit Linus").
- Red Hat/Fedora utilise SeLinux (Linus utilise Fedora ;-)).
- Novell va revenir à SeLinux. J'en suis persuadé.
T'as ici les deux distributions qui contribuent le plus à Linux (et de très très loins).
- IBM : Pro SeLinux.
IBM fait partit des plus gros contributeurs à Linux.
Les autres contributeurs majeurs (Intel par exemple) à Linux s'en foute que ce soit SeLinux ou AppArmor ou autre.
Si on prend en compte que l'aspect contribution (ou "méritocratie"), SeLinux l'emporte facilement.
Pour l'aspect "popularité" :
Debian semble plus impliqué dans SeLinux que AppArmor.
Ubuntu propose actuellement AppArmor mais ne ferme pas la porte à SeLinux.
Quand SeLinux sera plus accessible (avec des jolis outils graphiques), Ubuntu pourrait très bien passer à SeLinux. Ubuntu ne vise pas que le desktop (même si c'est l'impression que donne Ubuntu). Pour certains grands comptes ou administrations sensibles, il faut SeLinux.
Reste notamment Mandriva. Je ne vois pas Mandriva passez à SeLinux de lui-même.
Reste aussi peut-être OpenSuse que je vois rester avec AppArmor (Novell passant à SeLinux). M'enfin, OpenSuse est passé de Reiser à ext3 (décision prise avant les pépins juridiques de Hans).
Même si AppArmor est upstream, les choses peuvent changer. Et vite (pas en 2 ou 3 semaines évidemment).
[^] # Re: LSM
Posté par patrick_g (site web personnel) . Évalué à 5.
Je pense que ce n'est pas un article mais un post : http://lwn.net/Articles/240019/ ou encore http://lwn.net/Articles/252569/
Effectivement dans ceux-ci il évoque l'analogie avec la pile réseau en affirmant qu'il ne faut qu'une technologie dans le noyau pour que les devs se concentrent dessus.
L'ennui évidemment c'est que son avis doit être interprété à la lumière de ce qu'il est : un des plus visibles développeur de SeLinux.
Les autres projets ont un avis différent et je ne vois pas en quoi on pourrait le rejeter sans examen.
>>> Au niveau NSA, DOG (armé américhaine), certains grandes comptes, administrations, etc et les spécialistes qui sont largement reconnus (..) chez les personnes qui ont une forte crédibilité au niveau sécurité il y a consensus.
Dire qu'il y a consensus en citant la NSA c'est un peu bizarre. Ce sont les auteurs de SeLinux donc bien entendu ils soutiennent leur projet. L'armée américaine à évidemment le même avis que l'agence nationale de sécurité.
Ce qu'il faut bien voir c'est que SeLinux, aussi puissant soit-il, n'est pas la panacée. Les gens de Grsecurity et de Pax affirment même que ce n'est qu'une solution complexe poussée par des grosses boites afin de se faire du fric en support.
Je te colle le (long) paragraphe trouvé ici : http://www.grsecurity.net/lsm.php
"Conveniently, SELinux has made its way into the kernel, and all other security systems will be pushed out. Conveniently, many companies have their fingers in the SELinux pie and surely will be making money off "service" and "support" (hi Tresys, nice business model you have) for a system that is unusable for the market it's being pushed upon. Everyone please repeat the SELinux mantra: information flow graphs are important! SELinux is a proven model! What? Kernel exploits? Oh, that's right, SELinux conveniently leaves kernel exploits out of their "threat model," and no one questions it. By pure coincidence, ignoring this fact allows them to continue to propagate the myth that SELinux's information flow graphs are proven, and that SELinux provides a guarantee of security."
Donc non il n'y a pas de consensus autour de SeLinux. Les distros s'alignent car c'est la solution intégré en mainline mais tout le monde rouspète contre la complexité du processus de création d'une politique de sécurité et contre la lenteur quand il faut mettre à jour tous les labels.
Si une autre techno entrait en mainline qui soit plus simple que SeLinux on pourrait très bien assister a un ralliement de plusieurs distros. Les fans de SeLinux en sont très conscient et ils veulent vite virer LSM pour que cela ne soit pas possible.
Je trouve qu'il est assez révélateur de voir que James Morris s'est opposé à l'entrée de SMACK en mainline alors même qu'il a admis que le code était correct : "Smack itself looks fine. It seems like clean code with interesting ideas, and appears to be based upon sound principles."
Si Morris reconnait que SMACK est une bonne solution technique et qu'il apporte (enfin!) une relative simplicité dans la mise en place d'une politique de sécurité alors pourquoi il s'oppose à son entrée ?
Il s'y est opposé car l'entrée de SMACK en mainline signifierait l'arrivée d'un concurrent pour SeLinux et surtout l'arrivée d'un second utilisateur de LSM. Son projet de virer LSM pour ne laisser que SeLinux dans le noyau s'en trouverait anéanti.
On dirait vraiment un mec qui est arrivé le premier dans un bunker et qui essaye de claquer la porte derrière lui pour empêcher les autres d'entrer.
Je trouve donc que l'attitude de Linus est logique : attendre que la poussière de la controverse soit un peu retombée et en attendant garder LSM afin que toutes les options techniques restent ouvertes pour l'avenir.
[^] # Re: LSM
Posté par Nicolas Schoonbroodt . Évalué à 4.
Mais non, tu ne comprends pas. Il y a consensus entre tous les experts de la sécurité, à condition de définir expert de la sécurité "personne qui soutient SeLinux". CQFD.
[^] # Re: LSM
Posté par IsNotGood . Évalué à 0.
Bref, sans intérêt.
[^] # Re: LSM
Posté par IsNotGood . Évalué à 2.
C'est exactement ça. Merci de les avoir retrouvé.
Et puisque ça parle de SMACK, les développeurs smack ne sont pas opposés à la suppression de LSM et sont prêt à intégrer les spécificités de smack dans selinux. Ceci sera d'autant plus facile que LSM sera viré et donc le code sera plus propre, lancer des grosses modifications plus facile, etc. Les développeurs selinux accueillont évidemment les développeurs smack avec grand plaisir. D'autant (j'espère que tu l'as remarqué) que smack est jugé positivement par les développeurs de SeLinux. Donc les développeurs ne disent pas qu'il n'y a qu'eux qui font des trucs bien. Ils sont ouverts. Mais ouvert à des solutions solides et pas des trucs bancales comme AppArmor.
> L'ennui évidemment c'est que son avis doit être interprété à la lumière de ce qu'il est : un des plus visibles développeur de SeLinux.
Certe. Mais la vision "les développeurs SeLinux sont des tirants qui ne pense qu'à SeLinux et rien d'autre" est ri-di-cu-le.
Le soucis de James Morris, et je le crois vraiment saincère, ce n'est pas SeLinux spécifiquement, c'est Linux. C'est de faire de Linux le meilleur OS pour la sécurité. Ses arguments sont pertinents. Qu'il soit un développeur SeLinux ou non.
> Les autres projets ont un avis différent et je ne vois pas en quoi on pourrait le rejeter sans examen.
Un avis différent sur quoi ?
Les autres projets doivent aussi penser qu'il ne faut qu'une infrastructure de sécurité et pas 50 (ni même 2).
Lorsqu'il y a eu "compétition" pour le multithread, il restait deux solutions techniquement très intéressants et très proches NGT(c'etait ce non ?) et NPTL. Mais toujours il a été été considéré (aussi bien par ceux qui développaient NGT que NPTL) qu'il ne fallait au final qu'une solution pour thread. Ceci pour le bien de Linux.
NPTL a "gagné", NGT n'en a pas fait un fromage.
Le problème avec LSM, est qu'il n'y a pas vraiment de compétition puisqu'il n'y a pas de gagnant. On garde LSM est espérant faire plaisir à tout le monde. On est dans du politique correct contre productif.
> Dire qu'il y a consensus en citant la NSA c'est un peu bizarre.
Mouaif. Dit aussi qu'il n'y a pas de consensus au niveau W3C alors ...
La NSA n'est pas une entreprise qui doit vendre son bébé. Son rôle est de chercher les meilleurs solutions. La NSA reste ouverte. L'implication de Red Hat dans SeLinux le montre. Red Hat (et la communauté Linux qui travaille sur SeLinux) a énormément influencé la NSA. IBM, HP, etc participent aussi aux réflexions et travaux de la NSA.
La NSA ou SeLinux travaille beaucoup plus dans le consensus et la recherche de l'excellence que AppArmor. AppArmor c'est à l'origine un solution d'une boite proprio. Puis ça été repris par Novell et tu connais la suite.
Donc sur ce point, SeLinux est largement devant AppArmor, Grsecurity, etc.
> Ce qu'il faut bien voir c'est que SeLinux, aussi puissant soit-il, n'est pas la panacée.
Rien n'est la panacée. Le scheduler de Linux n'était pas la panacé, etc, etc.
Ça n'a aucun sens de dire ça.
> qu'une solution complexe poussée par des grosses boites afin de se faire du fric en support.
Ben dit ça aussi de Linux.
Ce type d'argument c'est de la connerie.
Teo de Raadt peut te faire la même tirade sur Linux ou gcc. C'est du grand classique niveau FUD.
> Oh, that's right, SELinux conveniently leaves kernel exploits out of their "threat model," and no one questions it. By pure coincidence
Tu peux me mettre un exploit ?
Tu peux me mettre la réponse de SeLinux ?
> ignoring this fact allows them to continue to propagate the myth that SELinux's information flow graphs are proven,
RHEL 5 a été certifier AEL+ lspp (le plus haut niveau) :
http://www.niap-ccevs.org/cc-scheme/st/?vid=10125
Et pour le "information flow graphs", voir la doc de RHEL 5.1 que j'ai donné dans ce journal.
Ton argumentaire ne tient pas. Il sous-entend que la NSA c'est des branleurs, Red Hat c'est des branleurs, etc, etc.
C'est un peu^Wtrès facile.
> contre la lenteur quand il faut mettre à jour tous les labels.
Et tu le fais quand ça ?
Pratiquement jamais.
Ça prend grosso modo autant de temps qu'un fsck.
La relabélisation totale je l'ai fait deux fois maxi (je me rappèle pas quand j'ai fait ça pour la derrière fois...). Des fsck beaucoup plus.
Enfin, tu peux mettre à jour qu'une partie des labels. Si t'as modifié que httpd, ben tu vas relabéliser que /var/www et peut-être /etc/httpd.
La sécurité c'est du sérieux. Tu ne t'amuses pas à bouleverser toutes tes règles de sécurité tous les matins.
Notes comme l'exemple de mon journal ne demande aucun relabélisation.
Enfin, tu dis plein de bien de smack, mais smack utilise aussi les labels. Donc le reproche tu peux aussi le faire à smack.
> Si une autre techno entrait en mainline qui soit plus simple que SeLinux on pourrait très bien assister a un ralliement de plusieurs distros.
Possible. Mais reste le problème d'avoir une solution que tu peux vendre au armée, aux adminstrations sensibles, etc...
Tu veux laisser ce marché aux autres ?
> Les fans de SeLinux en sont très conscient et ils veulent vite virer LSM pour que cela ne soit pas possible...
C'est une bête vision machiavélique.
> Je trouve qu'il est assez révélateur de voir que James Morris s'est opposé à l'entrée de SMACK
Il a donné ses raisons. Et il a dit :
> "Smack itself looks fine. It seems like clean code with interesting ideas, and appears to be based upon sound principles."
Ce qui montre que James Morris est quelqu'un d'honnète. Quand il dit que AppArmor pue, ben il le pense. Il ne le dit pas pour sauver SeLinux.
Alan Cox a aussi une honnèté remarquable et il trouve que AppArmor pue.
> Si Morris reconnait que SMACK est une bonne solution technique et qu'il apporte (enfin!) une relative simplicité dans la mise en place d'une politique de sécurité alors pourquoi il s'oppose à son entrée ?
Il n'est pas opposé à smack comme il est opposé à AppArmor. Il est opposé à LSM. L'entrée de smack implique de garder LSM.
> Son projet de virer LSM pour ne laisser que SeLinux dans le noyau s'en trouverait anéanti.
Son projet n'est pas SeLinux. Son projet est de faire de Linux le top de la sécurité comme Linux est le top pour le réseau. Et on y est presque avec Selinux. C'est un fait. Actuellement ça passe par SeLinux et ce n'est pas l'objectif de smack. Smack le reconnait et smack est d'accord pour bosser avec SeLinux si LSM est viré.
Enfin pour la simplicité, je le répète pour la millième fois, tu peux faire simple avec SeLinux si ton modèle de sécurité est simple. Faire des trucs type AppArmor avec SeLinux est possible (mais en moins bancale).
Tu peux faire des trucs super compliqué avec Gtk et aussi des trucs super simples.
> On dirait vraiment un mec qui est arrivé le premier dans un bunker et qui essaye de claquer la porte derrière lui pour empêcher les autres d'entrer.
C'est ta "petite vision" des choses. Alan Cox ne veut pas de AppArmor et il veut qu'une infrastructure sécurité dans Linux.
Mais à chaque fois que quelqu'un ou un organisme est favorable à SeLinux, tu les accuses d'arrière pensé. Pourquoi tu ne fais pas de même avec AppArmor (qui maintenant est une petite boite qui cherche a faire du pognon comme tu le "dénoncait" pour SeLinux) ?
Le noeud du problème est là. Des gens (toi apparament) ne veulent pas de SeLinux. Pourquoi ? Ben grosso-modo comme à une époque la majorité des gens étaient systèmatique contre Red Hat et ne voyait dans les choix et actions de Red Hat que des basses manoeuvres.
Si SeLinux c'est si puant, alors pourquoi Red Hat fait un succès avec RHEL ?
Pourquoi CentOS est aussi un énorme succès ?
Pourquoi Fedora a une si grande communauté de contributeur ?
SeLinux c'est ce qu'il y a de mieux actuellement sous Linux. Il y a quelques soucis pour faire plus simples, etc. Les travaux sont en cours et ça progresse fort.
SeLinux ce n'est pas qu'une communauté de gens qui veulent faire du pognon ou surfer sur une mode. C'est aussi une énorme communauté de développeurs. Le travail réalisé le prouve largement.
> Je trouve donc que l'attitude de Linus est logique
L'attitude de Linus a effectivement une logique (j'ai donné mon avis plus haut). Et je n'ai jamais dit que Linus était un anti-SeLinux primaire.
Mais je pense que son attitude est mauvaise pour Linux.
[^] # Re: LSM
Posté par patrick_g (site web personnel) . Évalué à 2.
C'est l'argument des devs de Grsecurity, pas le mien. Ne pas confondre le messager et la source.
>>> Alan Cox ne veut pas de AppArmor et il veut qu'une infrastructure sécurité dans Linux.
Manque de bol ce n'est pas Alan qui décide mais Linus.
>>> Des gens (toi apparament) ne veulent pas de SeLinux.
A l'origine mon post était là uniquement pour rebondir su la pique que tu avais envoyé à LSM dans ton journal. Je soulignais que LSM était là pour une raison : permettre l'existence d'autres acteurs que SeLinux.
Tu ne dois pas en inférer ma position personnelle en ce qui concerne SeLinux.
Par moi même je n'en pense rien car je n'ai pas les compétences pour avoir un jugement propre et argumenté sur ce sujet. Je me contente de t'indiquer, d'après mes lectures, que tout le monde ne semble pas avoir le même avis que les devs de SeLinux.
En tout cas cette polémique va forcer Morris et les autres a travailler comme des fous sur l'amélioration de la simplicité d'utilisation de SeLinux car c'est ça qui est perçu comme étant sa grande faiblesse. Ce sera bénéfique pour tous !
[^] # Re: LSM
Posté par IsNotGood . Évalué à 1.
Tu bosses à la poste ou c'est toi qui a choisi la source ?
> Manque de bol ce n'est pas Alan qui décide mais Linus.
Pourquoi manque de bol ?
Linus n'est pas là par hazard.
Le travail fournit par SeLinux est titanesque. L'éventualité que Linus soit d'accord pour virer LSM plane depuis 2005 je crois. Si Novell passe à SeLinux (ce que je crois), on n'aura une belle proportion de codeur Linux qui bosse pour une boite qui veut SeLinux. Si Linux accèpte AppArmor ou smack ou autre, il y aura de l'électricité dans l'air. Je crois que va dépasser l'incident diplomatique. J'ai du mal à imaginer ce qui va se passer.
> que tout le monde ne semble pas avoir le même avis que les devs de SeLinux.
Surtout les concurrents de SeLinux. J'y revient, mais "tout le monde" c'est qui ?
Que OOXML arrive a avoir un nombre respectable de vote à l'ISO, n'implique pas que je dois penser qu'OOXML est du bon matos et que finalement il lui faut la certification ISO comme ODF a la certification ISO.
Il y a qui et avec quel argument.
Les pro-OOXML peuvent être nombreux, pour moi ça ne change rien car les arguments (OOXML) sont nazes.
Les choix du noyaux doivent être principalement être motivé par les mérites techniques et non car telle ou telle solution est populaire. On est pas sur TF1.
Le seule reproche de SeLinux est la complixité. C'est compliqué mais ce que fait SeLinux est compliqué. C'est comme reprocher au code de gcc d'être compliquer. gcc est compliqué car ce qu'il fait est compliqué (optimisation, multi-language, cross-compilation, etc).
Ce n'est pas car je peux éditer à la main les règles de SeLinux que je dois savoir le faire pour profiter de SeLinux.
Comme ce n'est pas parceque j'ai les sources de Linux que je me sens obligé de bidouiller Linux lorsque je veux une fonctionnalité.
Lorsqu'on veut changer un paramètre de Linux (par exemple sa table de routage), je ne code pas des appels systèmes, je ne code pas des appels de fonction à la libc, je ne fais pas des scripts shell qui appellent ifconfig et route, j'utilise des outils de plus haut niveau (rc.* qui fait ça automatiquement, ou NetworkManager, etc). Sûr qu'aujourd'hui au moins 90 % des utilisateurs ne save pas utiliser ifconfig et route et encore moins coder des appels systèmes.
Ce qui est fait pour linux afin d'éditer les tables de routage peut-être fait pour SeLinux pour éditer les règles. Ça me semble évident à comprendre.
Que l'utilisateur final/lambda trouve aujourd'hui SeLinux compliqué a utiliser est logique. Je trouve ça compliqué aussi. C'est logique car le développement d'applis "user-friendly" commence à peine. Car l'architecture des règles commence à peine à être figée, etc. Mais les critiquef de complexité de Selinux venant de développeurs Linux frise le ridicule. Je ne vais pas voter contre iptables car je trouve /sbin/iptables imbitable et que ça fait des choses salement compliquée. Je ne vais pas voter pour iptables car system-config-firewall est simple d'utilisation. Si je suis développeur noyau je vais voter en fonction des fonctionnalités/performances que fournit iptables. Iptables fournit plein de fonctionnalité, il peut faire du compliqué et du simple, je vote pour. SeLinux fournit plein de fonctionnalité, il peut faire du compliqué et du simple, je vote pour. Mais certains dev Linux se mélange les crayons actuellement.
> que tout le monde ne semble pas avoir le même avis que les devs de SeLinux.
S'il y a un vote des codeurs de Linux pour choisir une infrastructure pour la sécurité, SeLinux arrivera probablement en tête. Et pas car les dev de SeLinux seraient majoritaire :-)
Si tu prends AppArmor, il est sévèrement critiqué par les dev Linux. Il reste le nouveau smack. Mais smack se veut simple et que simple. Il ne couvrira qu'un spectre des besoins en sécurité.
> En tout cas cette polémique va forcer Morris et les autres a travailler comme des fous sur l'amélioration de la simplicité d'utilisation de SeLinux car c'est ça qui est perçu comme étant sa grande faiblesse. Ce sera bénéfique pour tous !
Les pauvres. Après tout le boulot et le géni qu'ils ont fournit (gigantesque) on estime qu'ils méritent encore un coup de pied dans cul :-)
[^] # Re: LSM
Posté par Fabien (site web personnel) . Évalué à 2.
En quoi Linux est le top pour le réseau ? (note que je n'ai pas dit qu'il est mauvais).
[^] # Re: LSM
Posté par IsNotGood . Évalué à 1.
Tu préfères Windows ? HP-UX ? Solaris ?
[^] # Re: LSM
Posté par Fabien (site web personnel) . Évalué à 0.
Sinon, y a quoi dans les routeurs / switchs .... des diverses marques ?
Y a bien des OS là dedans (souvent dérivés de certains autres OS que l'on connait bien), et bien qu'on ne puisse pas les utiliser tel quels, ils existent et méritent la comparaison quand on parle de réseau.
[^] # Re: LSM
Posté par benja . Évalué à 1.
Malheureusement, l'os ayant du piquant & l'os à la serviette orange viennent de perdre leur capacité à faire du filtrage sur appels systèmes. [1]
En consultant http://fedoraproject.org/wiki/Security/Features , je me rends compte qu'il ne reste plus grand chose au poisson (kernel mis à part), il commencerait même à être distancé. Et c'est tant mieux car son objectif est de promouvoir la sécurité à l'ensemble des acteurs.
En quoi Linux est le top pour le réseau ?
Je suppose que le fait que des entreprises fabricant du matériel réseau de haute performance soient bien représentées dans le top des contributeurs à Linux est un gage de qualité.
[1]: http://undeadly.org/cgi?action=article&sid=2007080920130(...)
[^] # Re: LSM
Posté par IsNotGood . Évalué à -1.
Ce n'est pas tout à fait ce que je voulais dire. Fedora a peut-être moins de contributeur qu'Ubuntu ou Debian. Mais son niveau globale est assez élevé. C'est mon sentiment.
[^] # Re: LSM
Posté par khivapia . Évalué à 1.
oui.
Son rôle est de chercher les meilleurs solutions.
non. Son rôle est le principalement le renseignement.
(cf http://fr.wikipedia.org/wiki/National_Security_Agency ).
Notamment une de ses missions concerne l'intelligence économique et donc le renseignement industriel.
Croit-on vraiment que sa mission de protection du secret du gouvernement américain lui fait publier les algorithmes de chiffrement, programmes informatiques réellement utilisés ???
Le fait que les algorithmes de chiffrement doivent sans problème pouvoir tomber aux mains de l'ennemi, selon Kerckhoffs, ne signifie pas qu'ils les publient.
La NSA reste ouverte. L'implication de Red Hat dans SeLinux le montre. Red Hat (et la communauté Linux qui travaille sur SeLinux) a énormément influencé la NSA.
Ou tout au moins la version qu'elle veut bien fournir.
Rappelons que la NSA est également très ouverte vu qu'elle travaille avec Microsoft. (et n'oublions pas l'histoire étrange de la NSA_KEY pour alimenter un peu la paranoïa ;-) https://linuxfr.org//2007/07/16/22737.html#851467 et http://cryptome.org/nsakey-ms-dc.htm ;-) )
[^] # Re: LSM
Posté par herodiade . Évalué à 3.
De fait les principales distributions ont déjà choisi :
1- Les dernières versions de Mandriva, SuSE et Ubuntu intègrent AppArmor
2- Red Hat utilise SELinux
Le 1 permet de comprendre le fait qu'a cette occasion SuSE ai licencié une partie de ses développeurs AppArmor (à mon avis un appel du pieds aux autres distribution, à la « à votre tour aussi, de participer au financement du bidule, maintenant que vous êtes dépendants »).
Le 2 permet de relativiser les prises de positions bruyantes d'Alan Cox (et de IsNotGood)...
L'intégration d'AppArmor semble imminente à présent (probablement pour le 2.6.25), je suppose que c'est pour ça que les FUDistes se réveillent... Aussi : patrick_g a totalement raison de soupçonner les devs SELinux de vouloir enlever LSM pour virer la concurrence, c'est du moins pour ça que Linus les a rappelé à l'ordre (et puis, rappelons-nous leur réaction aux besoins derrière AppArmor : « ah, mais la simplicité à la AA, il suffit de l'implémenter au-dessus de SELinux » (ce qu'ils n'ont pas fait) et à Smack (« ah, mais il n'ont qu'à réimplémenter un smack au-dessus de SELinux » (ce qui ne sera pas fait)).
Concernant les modèles de sécurité : certains spécialistes (pas moi, mais par exemple chez OpenBSD) considèrent qu'un modèle valable doit être simple, clair et auditable. Iznogood, as-tu audité les modèles de sécurité en oeuvre sur ton poste pour savoir précisément de quoi ils te protègent, et de quelle façon (par ex. s'il n'y a pas, dans une police, une bourde qui laisse une énorme brèche ouverte dans la cathédrale ? ce genres de bourdes sont courantes sur les systèmes complexes). Combien de personnes ont audité ce jeu de règles ? Les contraintes sécurité de la NSA sont autant d'ordre bureaucratiques que techniques (d'où une forme assez byzantine du machin). Pour le commun des mortels, le fait qu'un modèle et des polices de sécurité soient intégralement lisibles auditable par beaucoup de monde (et auditable plus efficacement par les spécialistes) est bénéfique à la sécurité.
Cela étant posé, on sait qu'il faut être attentifs à certaines choses en déployant du AppArmor (ne pas autoriser les processus confinés à monter des périphériques ou faire des hardlinks, faire attention aux rennomages, confiner tout les autres processus susceptibles d'échanger des file descriptors avec celui qui nous intéresse, ...). N'empêche. Sans jeter l'opprobre sur SELinux, ça laisse la place pour d'autres modèles (Tomoyo, Smack, AppArmor, ...).
Voila ce qu'en dit Ted T'so, je souscris totalement : http://lwn.net/Articles/252588/
# SeLinux pour les nuls
Posté par Maclag . Évalué à 2.
Qu'appelles-tu utilisateur lambda?
- un utilisateur de linux (desktop, chez lui ou au boulot, il connaît un peu les lignes de commande sans être un grand maître du script qui tue en 3min).
A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
- un administrateur système linux (il connaît bien la ligne de commande, il sait gérer la sécurité, mais ce n'est pas l'un des 10 premiers experts mondiaux dans le domaine)
Même question: je suppose que suivant l'environnement et les utilisations du réseau, il aura un besoin plus ou moins pressant de SeLinux, mais peut-on classer des admins système dans les utilisateurs "lambda"??
En tout cas je te rejoins totalement sur la nécessaire facilité d'utilisation des systèmes de sécurité. Linux évolue vite et dans beaucoup de direction, le boulot des admins me semble de plus en plus dense et varié, ce qui signifie qu'ils auront de moins en moins de temps à consacrer sur un outil particulier, qui plus est un outil aussi délicat à utiliser correctement.
PS: Je ne suis pas admin, j'ai le droit de poser des questions c... :D
[^] # Re: SeLinux pour les nuls
Posté par IsNotGood . Évalué à 2.
Très bonne question. Réponse trop difficile. Joker.
> - un utilisateur de linux (desktop, chez lui ou au boulot, il connaît un peu les lignes de commande sans être un grand maître du script qui tue en 3min).
> A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
Ce type d'utilisateur ne va pas installer Bugzilla ou faire des règles SeLinux aux petits oignons pour un cgi d'apache qu'il développe.
> A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
SeLinux ça ne se vois pas. Pour se la péter, Compiz c'est mieux.
Sinon oui, c'est utile (NB: je ne dis pas indispensable). Par exemple sous F8, tous les programmes utilisateurs ne peuvent pas accéder librement à .gnupg ou a gpg-agent sans un contrôle. Si Firefox (ou bittorrent ou azureus ...) est cracké, tes clées gpg reste au chaud. Si Firefox fait n'importe quoi, une petite applet va tu prévenir. Tu peux aussi confiner Firefox.
Tu peux proposer deux Firefox (même binaire mais des règles SeLinux différentes d'appliqué). Un Firefox qui est peu confiné mais n'accèpte d'excécuter que les plugins signé par son distributeur. Un Firefox très confiné mais qui accèpte d'utiliser n'importe quel plugin.
> - un utilisateur de linux (desktop, chez lui ou au boulot, il connaît un peu les lignes de commande sans être un grand maître du script qui tue en 3min).
> A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
Ce type d'utilisateur sous Windows a besoin d'anti-virus. La réponse de Linux, ce n'est pas un anti-virus, c'est l'excellence dans le domaine de la sécurité.
[^] # Re: SeLinux pour les nuls
Posté par GeneralZod . Évalué à 3.
Perso, je comprends pas pourquoi les gens considèrent SELinux comme un truc inutile. Si on résume très grossièrement, SELinux ce n'est rien d'autre qu'un pare-feu applicatif ou un chroot amélioré. Il n'y a aucune magie derrière, SELinux est votre ami !
On associe à chaque application un domaine, à chaque fichier (incluant répertoires et ports) un contexte (de sécurité), chaque domaine n'a accès qu'aux fichiers dont le contexte lui est explicitement autorisé avec un service chargé d'appliquer et contrôler les règles.
En fait, c'est un peu plus complexe que cela, il y a également les translations de domaines, on peut limiter l'accès des domaines à certains utilisateurs et ...
Un exemple, je suis un utilisateur non expérimenté et que je veuille monter un serveur FTP pour partager des fichiers avec mes amis. Supposons que mon serveur FTP est compromis. Si je n'ai pas SELinux, game over, toute ma machine est compromise. Si j'ai SELinux, l'attaquant est enfermé dans la prison SELinux, il n'a accès qu'aux fichiers dont le contexte est accessible au serveur FTP, il est limité dans son escalade. Et c'est valable pour tout les services tournant sur sa machine ! Si il y a une faille inconnue dans un programme, SELinux limite la casse.
Il n'est pas rare de lire ce genre de choses:
http://www.linuxsecurity.com/content/view/128775/170/
SELinux est devenu accessible à tous, faut vraiment avoir un besoin spécifique pour avoir à le bidouiller où alors, c'est un bogue qu'il faut signaler au mainteneur du paquet.
J'ai trouvé un article sympathique qui explique clairement ce qu'est SELinux dans ses grandes lignes: http://www.supinfo-projects.com/fr/2005/selinux/
[^] # Re: SeLinux pour les nuls
Posté par ruz revr . Évalué à 2.
Dans le cas d'un poste de travail, si c'est une machine pour faire du développement utilisée par un utilisateur non root, SELinux gère cela comment ?
En général, ce que l'on veut pour un poste de travail, c'est vérifier le comportement des applications clientes (à cause des chevaux de troie), comment cela est compatible avec la possibilité de développer ?
Les distributions activant SELinux utilisent quel type de politique de sécurité dans ce cas d'une machine pour développeur ?
[^] # Re: SeLinux pour les nuls
Posté par GeneralZod . Évalué à 2.
Dans les cas particuliers comme Java ou MPlayer, tu disposes d'un booléen spécialisé pour une gestion plus fine.
En résumé, tu as une politique par défaut assez permissive, puis selon le service ou l'application, tu peux ajouter des règles plus strictes de façon granulaire. Comme le rappelle IsNotGood c'est aux spécialistes de la sécurité de définir ces règles, pas à l'utilisateur.
Pour les serveurs par contre, RH a une politique très stricte pour être certifié EAL4+/LSPP.
Dans ton cas, normalement, "it just works", à la rigueur tu dois toucher quelques booléens (très simple avec system-config-selinux), ou plus rare (et même très rare), tu dois faire la même manip que IsNotGood. Mais en général, si SELinux gueule c'est pour une bonne raison, si je dois toucher à un booléen alors que mon application tourne dans unconfined_t, je me poserais des questions.
http://fedoraproject.org/wiki/SELinux
[^] # Re: SeLinux pour les nuls
Posté par IsNotGood . Évalué à 1.
Tu veux s'avoir ce que t'apporte SeLinux ?
Clairement dans ce contexte c'est moins intéressant que pour une serveur critique.
> En général, ce que l'on veut pour un poste de travail, c'est vérifier le comportement des applications clientes (à cause des chevaux de troie), comment cela est compatible avec la possibilité de développer ?
SeLinux ce n'est pas que l'id de l'utilisateur. C'est l'id ET d'autres informations. Par exemple es-ce que le processus est un fils de /sbin/login, si c'est via ssh, qu'elle est l'adresse ip, etc. Dont tu peux par exemple avoir des privilèges différents si t'es connecté à la console ou via ssh.
Si ta bécane est attaquée et que le cracker obtient le compte root, il ne peut rien faire si par exemple le compte root n'a pas été obtenu via /sbin/login. Ceci dépend évidemment de la configuration SeLinux. SeLinux c'est une infrastructure, ce n'est pas une politique de sécurité. SeLinux supporte plein de politique de sécurité.
SeLinux fait aussi la distinction entre initialisation de la bécane (configuration des péiphériques, etc) et le moment où est elle est fonctionnelle. Lorsque le boot est terminé, certaines actions ne sont plus possibles.
> Les distributions activant SELinux utilisent quel type de politique de sécurité dans ce cas d'une machine pour développeur ?
Fedora il n'y a pas de distinction (RHEL 5 propose les règles stricts qui ne sont pas adaptées à un poste desktop, mais ses règles vont être abandonnées). Que ce soit un serveur où un desktop c'est grosso-modo la même configuration. Les utilisateurs sont confinés (NB: c'est un domaine où débute SeLinux qui jusqu'à maintenant c'est principalement concentrés sur la partie serveur).
Pour Fedora (ça sera la même chose pour RHEL6) il n'y a deux types de configuration :
- targeted
- mls
targeted (qui devient de plus en plus strict) convient pour les cas classiques (aussi bien desktop que serveur). targeted supporte support les modèles MAC et RBAC. Mls est pour Multi Level Security. C'est pour l'armée, etc... :
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/(...)
MLS est aussi utilisable en poste desktop.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.