Maintenant SELinux est ultra monolithique dans son approche
l'approche de selinux, c'est de mettre des labels et dire qui a le droit de faire quoi. la ou tu vois du monolitiques, d'autres vont voir de l'unification.
C'est clair - et c'est surement parceque c'est très très
difficile à faire qu'aucune distrib linux ou presque n'active
les ACL ou le mapping de ports par défaut ?
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça. Tout au plus, ça serait pour nfs et rpc, mais il me semble que c'est fait aussi.
Ca fait quand même un peu mal en 2013 d'avoir le serveur
Apache qui se lance en root
et de devoir mettre le stagiaire dans le groupe "www" pour
qu'il puisse modifier les CSS....
c'est vrai qu'en 2013, ça me ferait aussi mal au cul de pas utiliser de vcs pour le site web et de laisser le stagiaire directement modifier le site.
En ce qui concerne les bases postgresql tu peux faire
quelquechose de très similaire avec des labels multiples sur
FreeBSD en utilisant un partitionnement par tablespace.
D'une part, ça serait un gros hack, vu que ça implique d'avoir un servuer postgresql par personne que tu veux séparer ( car si tu as un serveur commun, les accès se font via le dit serveur, sous l'uid du dit serveur ). Et si tu as 1 serveur par personne, tu as quand même une consommation de ressources accrue, genre le cache, etc.
Donc la solution est encore une fois trés largement moins précise, loin de "très similaire".
si ca permet juste à deux machines configurées à
l'identique par un admin unique de dialoguer de façon sécure
c'est moyennement interressant)
encore une fois, c'est ce qui est prévu d'être utilisé par openshift online. Et il y a pas besoin que ça soit configurer à l'identique, juste de suivre les mêmes nomenclatures. Un peu comme dire "ton serveur web écoute sur le port 80 donc le web passe par ce port". Et le fait d'avoir une politique de sécurité unifié n'est pas une contrainte technique mais juste du bon sens. Il est claire que si tu restreint un accés à un type de document, faut le restreindre partout pour que ça soit globalement efficace.
Et comme tout ce qui concerne les questions de confiance dans le réseau, si tu as pas confiance dans l'autre machine, c'est pas un souci technique.
j'ai comparé les MAC BSD à du SELinux juste pour bien
expliquer que FreeBSD a mieux que les cgroups en stock
donc tu as comparé 2 frameworks de securité pour dire que Freebsd a un truc mieux pour gérer les ressources ? Et tu as comparé un truc granulaire et complet à un truc moins granulaire et qui fait la moitié. J'ai du mal à suivre, il suffit juste de dire "regarde, on remplace les cgroups par les jails pour la partie isolation", et "on remplace les cgroups par rctl pour la partie gestion de groupe", suivi par "du coup, si y a pas systemd, c'est bien parce qu'on pense que ça sert à rien, et qu'il faut pas attendre les BSDs pour avancer sur linux, on se débrouille bien tout seul".
[^] # Re: Tout va bien, je t'assure
Posté par Misc (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 4.
l'approche de selinux, c'est de mettre des labels et dire qui a le droit de faire quoi. la ou tu vois du monolitiques, d'autres vont voir de l'unification.
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça. Tout au plus, ça serait pour nfs et rpc, mais il me semble que c'est fait aussi.
c'est vrai qu'en 2013, ça me ferait aussi mal au cul de pas utiliser de vcs pour le site web et de laisser le stagiaire directement modifier le site.
D'une part, ça serait un gros hack, vu que ça implique d'avoir un servuer postgresql par personne que tu veux séparer ( car si tu as un serveur commun, les accès se font via le dit serveur, sous l'uid du dit serveur ). Et si tu as 1 serveur par personne, tu as quand même une consommation de ressources accrue, genre le cache, etc.
D'autre part, sepostgresql fait plus que ça comme on peut voir sur les objets :
http://selinuxproject.org/page/NB_SQL_9.0
Un tablespace postgresql va pas stocker une colonne, c'est la table, l'index ou la db.
http://www.postgresql.org/docs/9.2/static/sql-createtablespace.html
Donc la solution est encore une fois trés largement moins précise, loin de "très similaire".
encore une fois, c'est ce qui est prévu d'être utilisé par openshift online. Et il y a pas besoin que ça soit configurer à l'identique, juste de suivre les mêmes nomenclatures. Un peu comme dire "ton serveur web écoute sur le port 80 donc le web passe par ce port". Et le fait d'avoir une politique de sécurité unifié n'est pas une contrainte technique mais juste du bon sens. Il est claire que si tu restreint un accés à un type de document, faut le restreindre partout pour que ça soit globalement efficace.
Et comme tout ce qui concerne les questions de confiance dans le réseau, si tu as pas confiance dans l'autre machine, c'est pas un souci technique.
donc tu as comparé 2 frameworks de securité pour dire que Freebsd a un truc mieux pour gérer les ressources ? Et tu as comparé un truc granulaire et complet à un truc moins granulaire et qui fait la moitié. J'ai du mal à suivre, il suffit juste de dire "regarde, on remplace les cgroups par les jails pour la partie isolation", et "on remplace les cgroups par rctl pour la partie gestion de groupe", suivi par "du coup, si y a pas systemd, c'est bien parce qu'on pense que ça sert à rien, et qu'il faut pas attendre les BSDs pour avancer sur linux, on se débrouille bien tout seul".