J'aime beaucoup ta réponse. Je déplore juste qu'elle n'ait aucun rapport avec mon commentaire. J'ignore tout des pakistanais de la coupe du monde qui nivellent par le bas les footballers du Qatar. A mon avis c'est un peu vain comme initiative mais bon…
Mon commentaire est une attaque sur la réthorique utilisé dans ce genre de conflit. "Comme les gens ne peuvent pas choisir en toute liberté, on va les forcer dans notre direction à nous parceque c'est mieux que si les patrons le font", "Comme les syndicats sont incapables d'empécher la dégradation du travail, il faut absolument les laisser empécher la dégradation du travail", "comme les gens vulnérables sont vulnérables - il ne faut pas laisser d'autres gens abuser de leur vulnérabilité, quitte à les laisser tout aussi vulnérables qu'avant"
Et on en a comme ça des pelletées.
Le problème est complexe, merci d'éviter de balancer des arguments ineptes (oui un argument qui ne résiste pas à une analyse face à lui même est inepte) sous couvert de gauchisme outré.
Si vous voulez débattre, merci de ne pas partir du principe que a) tous les employés pauvres sont idiots, b) tous les employeurs sont riches et exploiteurs et c) toutes les personnes qui défendent la position opposée à la votre sont de sales égoistes inconscient du mal qu'ils font à eux-même et à la France…
Là par contre je ne comprends vraiment plus. Plus haut tu dis que le préfet n'a pas le droit de donner cette autorisation.
Je veux bien que tu me dise ou, le préfet a toute latitude pour autoriser les ouvertures le dimanche. La seule contrainte est de ne pas fausser la concurrence au sein de sa préfecture (c'est peut être ce point qui n'est pas clair). Si ça fausse la concurrence avec la préfecture d'à coté, c'est pas vraiment son problème.
Ok je comprends mieux, mais je me demande du coup pourquoi ce tribunal ne s'est pas déclaré incompétent.
Il est compétent. On a soulevé un problème de concurrence faussée qui est totalement de son ressort - et dont un tribunal administratif n'aurait que faire. C'est juste que personne ne s'attendait à ce que les magasin (qui ont juste une autorisation d'ouvrir, pas une obligation (oui dans certaines zones il y a obligation d'ouvrir le dimanche)) choisissent d'ouvrir malgré la décision de justice.
A noter que saisir un tribunal administratif n'aurait pas servi à grand chose - celui-ci aurait probablement juste dit que le préfet a bien le droit d'autoriser des ouvertures le dimanche.
A noter que les magasins prennent un risque, je suis sur qu'il y a pleins de gens compétents dans les hautes sphères judiciaires qui cherchent comment démolir la position de Castorama/Leroy-Merlin. Et si ils ne trouvent pas je prédis du contrôle URSSAF sévère. Mais la ça fait une semaine que ça dure, et plus le temps passe, plus le gouvernement va être obligé de pondre une nouvelle loi qui clarifie la situation pour ne pas désavouer une des grandes institution française (personne n'a envie du dire que la préfecture est plus forte ou moins forte que le tribunal de commerce). Clarifier la situation c'est typiquement ce que Bricorama veut (et probablement Castorama et Leroy-Merlin aussi).
Comme tout bon français, j'ai regardé les résultat avant de voter - et là horreur, Patrick_G est moins impopulaire que la tribune (2 vote pour lui, contre trois pour la tribune).
Je en pouvais pas laisser faire ça, et j'ai donc voté Patrick_G.
Je suis assez surpris. C'est une hiérarchisation qui ne me semble pas intuitive. Il me semble que la loi est au dessus des décrets préfectoraux, le juge ne faisant qu'appliquer la loi.
Tout d'abord le préfet n'est pas au dessus des lois, c'est bien entendu la loi qui permet au préfet de délivrer les autorisations d'ouverture le dimanche.
Ensuite il existe de nombreuses instance judiciaire qui peuvent claquer le beignet du préfet si celui-ci va trop loin - mais ce sont des tribunaux administratifs (le conseil d'Etat a tout pouvoir pour broyer du préfet par pack de douze si il lui en prend l'envie).
Là c'est le tribunal de commerce (je pense, l'information est difficile à valider sur le net) qui interdit une chose que le préfet a autorisée. Comme seul un tribunal administratif peut invalider un arrêté préfectoral, les magasins décident de passer outre.
J'espère que le journal d'un avocat se chargera de m'expliquer ça dans le détail :)
Ça serait bien en effet. Mais c'est rare que Eolas s’intéresse à ce type de sujet.
Et si le préfet ne respecte pas la Loi et délivre des autorisations bidons, on envoie l'armée?
Techniquement oui. La gendarmerie, qui fait partie de l'armée peut être mise à disposition du préfet - mais n'est jamais aux ordres du préfet. Donc on peut imaginer que le gouvernement fasse envoyer la gendarmerie pour contrer le préfet, mais bon ça sera toujours plus rapide de le destituer et de le ramasser avec des méthodes classiques une fois qu'il a perdu son mandat. (Méthode classique qui peut impliquer la gendarmerie, suivant le lieu d'ailleurs)
Ceci dit, le préfet ne peut pas délivrer d'autorisations bidons - parce que justement c'est le coup de tampon de la préfecture qui valide les autorisation.
Dans le domaine des braderies et liquidations de stock, il y a un cadre légal très strict (un magasin ne peut pas se mettre en braderie tout le temps, les magasins d'alimentaire ne peuvent pas liquider les stocks, les produits achetés récemment doivent être retiré des liquidations ou des braderies etc.) Donc dans le cas d'une liquidation par arrêté préfectoral (suivant la formule consacrée) le préfet peut outrepasser son mandat et délivrer des autorisations qui sont contraire à la loi.
Mais dans le cadre d'une ouverture le dimanche, il n'existe pas de limitations autre que le fait que le préfet doit faire attention à ne pas fausser la concurrence. En d'autres termes si dans sa préfecture il y a plusieurs magasins similaires il n'a pas le droit d'en autoriser certains à ouvrir, mais pas d'autres.
Sauf que bien sur au niveau légal il existe pleins de magasins qui ont le droit d'ouvrir le dimanche automatiquement ou presque (si vous êtes dans une zone très touristique, si vous êtes proches d'un monument historique ouvert au public, si vous êtes dans certaines zones commerciales, si le dimanche est un jour de marché d'une certaine ampleur, si votre activité est fortement lié à celle d'un autre magasin qui a le droit d'ouvrir le dimanche etc.) Donc de base la concurrence est déjà faussée, parfois même volontairement pour attirer des enseignes dans un lieu délaissé des commerces.
Dans le cas de Paris et de la proche banlieue - ou on peut changer de sous préfecture en faisant 100m dans n'importe quelle direction ou presque, les enseignes qui sont situé 100m trop à gauche et qui doivent fermer le dimanche trouvent la blague saumâtre, vu que de l'autre coté du pont leur concurrent direct peut ouvrir.
C'est exactement ce qui a poussé Bricorama a porter plainte.
Oui c'est dingue que des gens demandent à ce que la loi soit respectée.
Comme par exemple dans le cas de Leroy Merlin Ivry, l'accord de la préfecture non qui les autorise à ouvrir le dimanche pendant encore 6 mois ? Ou encore le magasin de Sainte Geneviève des Bois qui a son autorisation d'ouvrir depuis des années - autorisation qui a été renouvelée en mai ?
Le truc légal ici c'est qu'il s'agit d'un combat entre l’exécutif et le judiciaire, la préfecture et le tribunal de commerce pour être exact, le tout à cause d'un flou assez vaste laissé par le législateur. Tous les magasins qui ouvrent sont dans la légalité. Pour être caricatural il s'est passé ceci :
a) Les magasins n'ont pas le droit d'ouvrir le dimanche
b) La préfecture donne explicitement le droit d'ouvrir le magasin bien que ce ne soit pas autorisé normalement
c) imbroglio juridico-syndical, le juge rappelle aux magasins qu'ils n'ont pas le droit d'ouvrir le dimanche
d) Les magasins répondent qu'ils sont au courant, mais qu'ils ont une autorisation de la préfecture qui les autorise à ouvrir quand même - dont acte.
Le juge ne peut pas invalider l'autorisation de la préfecture, les magasins disposent donc d'un moyen légal de passer outre toute décision de justice sur la fermeture le dimanche. Grosso-modo ils ont un papier sur lequel il est marqué "même si c'est interdit (d'ouvrir le dimanche), vous pouvez le faire quand même."
Si on ajoute à cela le fait que si le juge veut faire appliquer sa décision de justice "de force", par exemple en envoyant la police fermer le magasin, il devra passer par la préfecture pour mobiliser les agents.
Au fait ça n'a rien à voir, mais le mouvement n'a pas été initié du tout par les syndicats (qui cherchent juste à attraper la balle au vol) - mais par Bricorama, qui lui n'avait pas toutes les autorisations nécessaires et a donc été contraint de fermer (ou de modifier ses horaires) le dimanche. C'est lui qui a porté plainte - les enseignes ayant des produits et services similaires, la concurrence est faussée si l'une peut ouvrir et pas l'autre.
Tu ne réfléchis pas bien: le but des magasins est de passer d'un travail bien rémunéré le dimanche pour certains à un travail pour tous le dimanche payé une misère.
Ah bon ? C'est pas pour le droit d'ouvrir le dimanche quitte à payer de gros suppléments aux salariés parce que 40% du chiffre d'affaire est concentré sur le dimanche. Mince j'ai encore du me tromper d'univers ce matin en me levant.
Si le choix des salariés était réel, ça ne me poserait pas de problème. Il ne faut pas rêver, il ne l'est pas.
Donc comme les salariés ne pourraient pas choisir de travailler le dimanche librement, on va les forcer à ne pas bosser le dimanche ce qui est tout de suite beaucoup plus respectueux de leur libertés.
Donc comme les syndicats sont incapables de faire leur boulot (comme par exemple en empêchant des abus de se créer sur le travail du dimanche), on va les laisser faire leur boulot (comme par exemple en bloquant le travail le dimanche).
Donc comme les gens pauvres, précaires ou peu diplômés sont vulnérables et sont prêt à tout pour gagner quelques sous et améliorer leur quotidien en travaillant le dimanche, on va éviter que l'on puisse les exploiter facilement en leur fournissant du travail le dimanche - et surtout laisser leur quotidien comme il est (c'est pour leur bien en fait).
Merci de ne pas tomber dans la condescendance.
Qui pense que les salariés sont trop bête/trop mal informés/trop aveuglés par le court terme pour prendre une décision lucide vis à vis de leur dimanche ?
Qui estime que les patrons sont des créatures viles contre lesquelles les malheureux quidam inconscient et naturellement sans défense doivent être protégés ?
Qui assène que si l'on commence à aller dans cette direction, on ne pourra plus jamais faire machine arrière, que l'on aura jamais la force de se mobiliser et d’empêcher un glissement progressif vers les trois huit pour tout le monde, samedi dimanche inclus ?
La condescendance on se la frappe de plein fouet de la par des "anti travail le dimanche".
N.B : Je ne suis pas particulièrement friand du "travail le dimanche" notamment parce que la raison pour laquelle cela fonctionne financièrement est justement parce que 90% des gens ne travaillent pas le dimanche. Mais dans le cas de l'industrie de loisir (à laquelle appartient indubitablement le bricolage) il convient d'avoir une vraie réflexion sur les aménagements possibles d'horaire et les compensations financières des gens qui travaillent le dimanche.
En lisant l'article, j'ai vu que la quasi totalité des applications sont écrites dans des langages différents. Une en Python 3, une en javascript, une en Vala et le reste de GNOME est souvent en C et Python 2.
Ben à la base Gnome c'était un environnement de bureau. Avec le passage à Gnome3 on a commencé à glisser doucement vers l'OS (la quantité de composants systèmes bas niveau dont Gnome3 a absolument besoin est tout simplement effarante). Gnome 3.10 n'est juste que la première mouture de la "distribution" Gnome pour l'OS Gnome 3. Je dis distribution parceque tous les ingrédients sont réunis - gestionnaire de package, mise à jour, interdépendance forte des composants qui doivent être compilés de façon uniforme, choix des outils systèmes etc.
On glisse encore un peu et le concurrent de Gnome 4 ca ne sera pas KDE ou XFCE mais Debian…
Il est déjà sorti, mais il a été censuré par le pouvoir en place qui lutte activement contre la progression de la connaissance libre, gratuite, internationale et sans contraintes.
Je suis un grand fan de PostgreSQL et il n'y a jamais eu aucun problème de mise à jour avec PostgreSQL MAIS ce coup ci le modèle de mappage mémoire a été modifié. C'est une excellente nouvelle parceque ca va éviter à tous les admins de régler leur shmax aux petits oignons pendant des jours, mais ca implique aussi qu'il y a potentiellement des bugs vicieux qui peuvent se rpoduire sur certaines configs.
A garder un bon moment en test avant de migrer donc.(Plus que d'habitude en tout cas).
Ceci dit ça n'enlève rien à ce qui est le meilleur framework de données libre au monde.
Tu te focalises sur la gestion des personnes alors que ce qui est important c'est la gestion des briques et de leurs interactions.
Bon apparemment je ne dois pas parler en français. Je vais donc être clair, au risque de paraitre un peu vulgaire :
Dans le cadre de cette discussion, qui porte sur la sécurite je me FOUS COMPLETEMENT de l'aspect gestion de projet.
Voilà. Est-ce clair ? Je sais très bien gérer un projet merci.
Mais même si les VCS c'est bien, même si ca permet de faire pleins de choses, même si ca apporte énormément en terme d'organisation etc. Ca n'apporte rien au niveau sécurité.
C'est comme les duplications et les sauvegardes - ca n'a rien à voir. Ca ne veut pas dire que les duplications soient meilleures que les sauvegardes, ou que les sauvegardes sont au dessus des duplications - ca n'a juste **AUCUN RAPPORT*
Ben les VCS et la sécurité c'est pareil. Les ACL apportent de la sécurité, les VCS non. Ce qui ne veut absolument pas dire que l'on peut remplacer les VCS par des ACL. Ce sont deux choses distinctes.
Mais la justification utilisées me laisse très perplexe. Vérouiller qui fait quelle modification sur la prod avec une granularité fichier/rep ca sent pas bon du tout. L'info du mec qui a fait le changement devrait être perdu depuis longtemps entre le VCS, le packaging et le déploiement et ce n'est pas là qu'il faut s'en soucier.
Je te rassure, je ne fais absolument pas comme ça. Je vérouille au niveau fichier/repertoire par mission. Chaque mission correspond à un groupe au sens Unix, et chaque groupe a ses propres ACL. Et mon VCS/packageur/script Node et j'en passe n'appartienent à aucune mission et n'ont aucun droit pour faire la moindre modif sur le système. Ils assument les droits utilisateurs qui sont donnés par la mission de l'utilisateur.
Tout d'abord un grand merci de m'expliquer ce qu'est un VCS quand j'explique depuis maintenant 5 posts que la question posées n'a rien à voir avec les VCS.
Je sais ce qu'est un VCS, comment on s'en sert, je les utilises quotidiennement (et plutôt deux fois qu'une vu que le backup des systèmes est aussi un VCS sur mes machines), je fais du centralisé aussi bien que du distribué etc.
Donc tu as fait des handbook pour le FreeBSD ? Très bien. Estc-e que les modifications que tu as faites se sont retrouvées automatiquement en ligne ?
Non hein ?
Ben voilà.
Maintenant on se moque que ce soit l'admin FreeBSD himself en personne, ou une personne qui qu'elle soit qui a les droits d'administration d'un projet (Hint : il n'est pas forcément root sur tout le domaine) qui ait fait le taf. La sécurité dans les projets FreeBSD vient de la validation humaine. Rien ne se fait sans validation humaine si le mec qui soumet des modifs n'a pas les droits de commiter (i.e : il est probablement pas "stagiaire").
Après comme tu le dis très bien quand il y a 200 briques projets, des centaines de milliers de lignes de codes sur des sujets aussi variés que les I/O bas niveau et les CSS level3 compatibles IOS, c'est rarissime d'avoir assez d'admins (i.e chef de projets/commiteurs/responsables etc. par forcément des mecs root) pour faire une validation manuelle et fiable de tout ce qui passe. C'est ce que je soulignais en disant "L'admin va probablement trouver la blague saumâtre".
Et les VCS n'aident absolument pas à résoudre les problèmes de sécurité qui se posent.
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà… Ce n'est pas la bonne réponse.
Avec les ACL le mecs ne peut effacer que les fichiers sur lesquels il a les droits. Donc le mec peut lire le code HTML, mais n'avoir le droit que de modifier certains fichiers CSS. Alors que les fichiers sont lisibles aussi bien par le proxy nginx que par apache et qu'un autre stagiaire ne peut modifier que les fichiers images.
Sans ACL (et sans MLS/MAC ) forcément, il faudra mettre des droits inutiles à un des uid qui écrivent ou lisent sur le disque. Peut importe que ce soit l'uid du VCS, d'apache ou de nginx. Les fichiers ont un propriétaire et un groupe - avec à chaque fois un seul set de droits. Forcément tu augmentes la surface d'attaque en conservant les droits Unix plutôt qu'en mettant des ACL bien foutu. Et peut importe que ce soit le stagiaire, le VCS, Apache, ou nginx qui ait trop de droits (ie accès à des fichiers auquel il ne devrait pas avoir accès) ca pose un problème de sécurité qui est ultra-simple à résoudre.
Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis.
Non. Elle va livrer des artefacts dans une section artificiellement restreinte d'un contexte beaucoup trop large - et on reporte sur le processus de déploiement la charge de limiter, via du code userspace, la zone d'impact de ce déploiement.
La surface d'attaque est l'ensemble de tous les répertoires que l'utilisateur (au sens uid) VCS peut lire ou écrire. Sans ACL cette surface est disproportionnée par rapport au besoin.
Le stagiaire comme la plupart des contributeur il a un espace de travail une branche dédiée où sur une branche d'intégration qui n'est pas directement reliée à la production.
On se moque que ce soit relié directement ou indirectement à la production. Le stagiaire a les droits sur le serveur et basta.
C'est amusant cette façon que vous avez tous de confondre organisation et sécurité - surtout dans un thread qui est centré sur les access control.
Peut importe que le chemin soit tortueux, passe par trente applis qui redistribuent les fichiers dans tous les sens et que quinze procédures de vérifications automatiques se déclenchent - la question est "le stagiaire peut-il créer des fichiers sur un répertoire situé sur le serveur sans l'intervention d'un admin ?". Si la réponse est oui, le stagiaire a les droits sur le serveur. (Et si la réponse est non - il y a des admins qui doivent sérieusement trouver la blague saumâtre).
Je ne remets pas en cause les avantages d'un VCS, mais il faut bien se rendre compte qu'un VCS est un outil d'organisation, pas de sécurité - même avec un VCS, même avec un système très complexe de validation automatique, le stagiaire a toujours les droits sur le serveur. Ca ne veut pas dire qu'il a un uid qui peut se loguer sur le serveur et écrire dans un répertoire directement - ça veut dire qu'il fait une manip sur une machine et que quelques temps plus tard un fichier sur le serveur est créé/modifié/supprimé.
Les VCS permettent de s'organiser pour éviter les accidents et pouvoir revenir facilement en arrière au cas ou un accident se produit quand même. Mais ils apportent 0 au niveau sécurité.
Et quand le stagiaire a besoin de pouvoir écrire (même indirectement) sur un répertoire qui doit être lisible par Apache mais pas par le monde entier, on se retrouve très vite limité avec les droits Unix standard - sur toute machine (même mono utilisateur) les ACL devraient être activés par défaut sur toutes les partitions, et l'admin ne devrait les éteindre que si il a une excellente raison de le faire. Ce n'est pas le cas aujourd'hui.
Le stagiaire peut (et doit) commiter dans le VCS…et n'a même pas d'accès au serveur
Le stagiaire a accès à un truc qui accès au serveur ("un truc" pouvant être composé de milliers de programmes à la queue leu leu).
Donc le stagiaire a des droits sur le serveur.
Le truc qui va écrire au final sur le disque dur du serveur (via deb, rpm, shadow copy etc.) doit avoir des droits sur le répertoire cible sur le serveur. Avec des ACL on peut limiter la surface d'attaque - avec des droits unix de bases on ne peut pas avoir des groupes qui ont des droits en lecture, d'autres qui ont des droits en écriture etc. et on se retrouve systématiquement à donner plus de droits qu'il n'en a besoin au stagiaire (Même si c'est au travers de 112 000 outils).
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.
Unification et coté monolithique n'ont pas grand chose à voir. C'est très bien que SELinux unifie les politiques d'accès (sans ironie hein), mais c'est un peu domage de devoir mettre en place tout le framework de a à z pour une politique de 3 lignes. J'ai bien conscience que vu la nature et les ambitions de SELinux il n'est pas possible de découper le framework en pleins de petits morceaux utilisables séparément, mais je préfère quand même l'approche biba de FreeBSD.
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Sur quelle distribution ? Parceque si les outils pour les ACL sont intégrés, c'est rare que les FS aient les ACL activés par défaut. Je change pas de sitrib tous les deux jours, mais l'année dernière il n'y avait guère que Suse et Fedora qui activaient les ACL par défaut.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça.
Tout simplement faire démarrer un service en écoute sur un port local non privilégié et rajouter une règle firewall pour faire le lien. Ca évite de devoir lancer tout un tas de service en utilisateur root (même si après les privilèges redescendent - c'est quand même pas top).
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.
Même avec un VCS, à un moment ou à un autre il va bien falloir aller écrire dans /var/www (ou autre répertoire) et là sans les ACL tu as deux solutions : soit tu donnes le groupe www a tous les utilisateurs susceptible de devoir modifier le site (ou faire un commit si tu préfères), soit tu ajoutes l'utilisateur apache dans 200 groupes.
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 ).
Alors distinguons bien deux cas :
a) Il s'agit d'un utilisateur avec un compte et un uid qui est logué en console et qui utilise, par exemple, psql - et là avec les labels multiples le mec il peut toujours se brosser pour accéder au contenu d'un tablespace qui n'est pas autorisé. (Je pensais que tu parlais de ce cas là)
b) Il s'agit d'un utilisateur logué à distance (par exemple sur le port 5432 via réseau) - et là de toutes les façons les accès se font via le serveur, sous l'uid du serveur. La seule chose qu'apporte SE-Postgres dans ce cas c'est que les restrictions et les droits ne sont plus validé seulement contre le système interne à Postgres mais aussi vis à vis d'un jeu de police de sécurité SELinux. Cependant si le plugin est compromis (ce qui implique qu'il n'était pas lui même protégé par une policy - ce qui serait idiot je l'admet) SE Linux ne verra rien passer des requètes faites à PostgreSQL.
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.
La question est de quoi ai-je besoin pour faire confiance à l'autre machine ? Si c'est juste tester la présence d'une clef ipsec est très bien dans le rôle, si j'ai besoin de plus que ça il faut que je sache le valider chez une machine tiers. A aujourd'hui si j'ai besoin de plus que la présence d'une clef privée, il faut que je maintienne le serveur complètement - ce qui peut être lourd. CIPSO était supposé répondre à ce problème - on devait être capable de s'envoyer des paquets certifiés qui anoncnet que le serveur distant est bien en train de faire tourner un apache à jour avec mod_rewrite désactivé, que le routeur machin droppe les paquets DHCP ver telle ou telle branche réseau, que les url de type xxx://#!!%/*.truc sont interdite etc.
Est-ce que aujourd'hui c'est possible vis à vis d'une machine que je n'administre pas ? Oui/partiellement/non ?
proche, tu veux dire "si on rajoute les trucs manquants"
Non par proche je veux dire "Dans le même esprit que". C'est clair que SELinux fait pleins de choses que MAC ne fait pas, et que MAC avec les jails fait des trucs que tu peux imiter avec SELinux+OpenVZ - mais tu vas y passer un moment quand même.
Maintenant SELinux est ultra monolithique dans son approche. Chez FreeBSD tu vas avoirs plusieurs outils pour arriver grosso modo au même résultat.
C'est vrai que SELinux a une granularité plus fine que MAC (nettement) - mais c'est vraiment trop lourd à mettre en place et à maintenir.
et "si on code une policy, parce c'est tellement simple que personne commence, sauf des boites qui gardent ça pour elle grace à la license BSD" ?
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 ? 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….
Parmi les trucs manquants, tu peux mettre des labels sur les bases postgresql, sur les paquets réseaux via CIPSO ( notamment utilisé par openshift afin de sécuriser les échanges entre containers ), ou directement sur X.
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.
En ce qui concerne CIPSO j'ai décroché depuis 2007 environ. Je ne sais pas du tout ou ca en est. En 2007 ils relancaient une grosse phase de draft, la 42ième depuis 1990. On a tenté de mettre en place un truc de tests pour des échanges en trusted Solaris et NetLabel. Ben plouf. Une recherche rapide sur internet me donne une page blanche à l'IETF et deux liens de 2006 sur les NetLabels Linux. En insistant un peu on trouve trois lignes dans un article Wikipedia sur Solaris. Vrai question : "C'est utilisé ce truc là ?" (Attention par utilisé je veux dire est ce que l'on arrive à faire négocier ensemble des machines qui n'ont pas la même version du kernel redhat, avec les policy redhat et tout le toutim - si ca permet juste à deux machines configurées à l'identiques par un admin unique de dialoguer de façon sécure c'est moyennement interressant)
Pour en revenir au sujet de mon post, j'ai comparé les MAC BSD à du SELinux juste pour bien expliquer que FreeBSD a mieux que les cgroups en stock. C'est très largement possible de faire tout ce que font les cgroups avec MAC dans le cadre d'un portage systemd - surtout vu la façon assez légère dont les cgroups sont utilisés par systemd.
Awé ? I need explanations! (ce n’est pas ironique).
Dans les MAC il y a à peu près tout ce que font les CGroups et bien plus. On a du partitionnement, de la délégation de privilège, de l'isolement, de l'héritage de droits etc.
Pour faire court, il y a dans FreeBSD un système qui est proche de SELinux niveau fonctionnalité, mais nettement plus utilisable et lisible.
Ensuite le système d'init lui même n'est pas sysV - Il s'agit de l'init BSD historique - en l'occurence RC - Dont la conversion vers un système type upstart/systemd serait très simple. Les fichiers RC sont déjà très très normés, les places pour les différents éléments sont connus etc. Il faut bien voir que les *BSD ne fournissent pas un kernel mais tout un OS - de fait il n'y a qu'un seul système d'init et un seul groupe qui le maintien. Le bazar que l'on a eu au niveau des inits Linux ne s'est jamais vraiment produit sous BSD.
Il existe tout un tas d'init alternatifs qui fonctionneraient très bien sous FreeBSD si ons se donnait un peu de mal (OpenRC par exemple).
Après malgré la facilité qu'il y aurait à changer le système d'init et le fait que le système posséde depuis des années des utilitaires éprouvés pour faire tourner la nouvelle solution (certaines opérations sont déjà asynchrone au boot depuis des lustres) - ben personne de sérieux ne voit l'intéret de s'y mettre. En l'état actuel de qualité du rc, un changement permettrait peut-être de gratter une dizaine de secondes au boot (dans certaines conditions très particulières - pas de DHCP ou de firmwares à charger par exemple) mais n'aurait pas d'impact majeur. Le point le plus interressant étant ce que ça pourrait apporter à une machine avec beaucoup de jails qui tournent…
On se rend donc compte que les BSD sont en train de se faire dépasser par le Hurd, ce qui est un peu la honte.
Non, non. Tout est OK. BSD possède tous les outils nécessaires pour implémenter un init façon systemd très facilement. Regarde simplement du coté des MAC de FreeBSD par exemple.
Donc si un jour il y a vraiment obligation d'avoir un truc similaire, on l'aura très très vite sous BSD.
En fait, quand c’est pas assez intégré on râle, si c’est trop intégré on râle.
Le problème de systemd c'est pas son integration, c'est la liste importante de choses que tu ne peux plus faire. Les daemon mono-processus par exemple sont ingérables, one ne peut plus passer de variabales d'environnement ou de paramètres aux services de façon dynamique. Le service A ne peut plus demarrer le service B sans passer par systemd - ce qui ne peut se faire que si le service A a des droits monstrueux. Et il y en a comme ça une pelletée.
Ce n'est pas une couche en plus. On peut utiliser journald tout seul.
Non. C'est totalement impossible et assumé par Lenart. Journald ne sait discuter qu'avec systemd dans un environement (structure du file system, variables de kernel, outils d'interaction etc.) prévu pour.
La compatibilité syslog, c'est juste de la rétrocompatibilité et pour ceux qui préfèrent les logs en texte (même si journald fournit de quoi filtrer ses logs et sort du texte sur la sortie standard quand on appelle journalctl). Bref, c'est totalement inutile dispensable.
Oui, déjà il faut aimer les logs textes passés par la moulinette journald, et ensuite le mec qui a son journal binaire corrompu pour une raison X ou Y, il fait quoi ? Ben généralement il est super content d'avoir les vieux logs textes totalement dispensables - mais lisibles eux.
[^] # Re: travail hebdomadaire
Posté par Kaane . En réponse au journal Travail dominical. Évalué à -3.
Merci pour cette barre de rire. Tu as illuminé ma journée.
[^] # Re: Hors de question !
Posté par Kaane . En réponse au sondage Ce que je souhaiterais voir disparaître de LinuxFr.org.... Évalué à 6.
T'en fais pas, j'ai les noms. Vous avez tous un contrat sur votre tête maintenant ;-)
Hein ? Qu'est-ce que tu dis ? Parle plus fort, tu t'es tellement fait enfoncer par le sondage qu'on t'entend mal maintenant…
[^] # Re: travail hebdomadaire
Posté par Kaane . En réponse au journal Travail dominical. Évalué à -1.
Bonjour,
J'aime beaucoup ta réponse. Je déplore juste qu'elle n'ait aucun rapport avec mon commentaire. J'ignore tout des pakistanais de la coupe du monde qui nivellent par le bas les footballers du Qatar. A mon avis c'est un peu vain comme initiative mais bon…
Mon commentaire est une attaque sur la réthorique utilisé dans ce genre de conflit. "Comme les gens ne peuvent pas choisir en toute liberté, on va les forcer dans notre direction à nous parceque c'est mieux que si les patrons le font", "Comme les syndicats sont incapables d'empécher la dégradation du travail, il faut absolument les laisser empécher la dégradation du travail", "comme les gens vulnérables sont vulnérables - il ne faut pas laisser d'autres gens abuser de leur vulnérabilité, quitte à les laisser tout aussi vulnérables qu'avant"
Et on en a comme ça des pelletées.
Le problème est complexe, merci d'éviter de balancer des arguments ineptes (oui un argument qui ne résiste pas à une analyse face à lui même est inepte) sous couvert de gauchisme outré.
Si vous voulez débattre, merci de ne pas partir du principe que a) tous les employés pauvres sont idiots, b) tous les employeurs sont riches et exploiteurs et c) toutes les personnes qui défendent la position opposée à la votre sont de sales égoistes inconscient du mal qu'ils font à eux-même et à la France…
Voilà ce que disait en substance mon commentaire.
[^] # Re: 56%
Posté par Kaane . En réponse au journal Travail dominical. Évalué à 3.
Là par contre je ne comprends vraiment plus. Plus haut tu dis que le préfet n'a pas le droit de donner cette autorisation.
Je veux bien que tu me dise ou, le préfet a toute latitude pour autoriser les ouvertures le dimanche. La seule contrainte est de ne pas fausser la concurrence au sein de sa préfecture (c'est peut être ce point qui n'est pas clair). Si ça fausse la concurrence avec la préfecture d'à coté, c'est pas vraiment son problème.
[^] # Re: 56%
Posté par Kaane . En réponse au journal Travail dominical. Évalué à 5.
Ok je comprends mieux, mais je me demande du coup pourquoi ce tribunal ne s'est pas déclaré incompétent.
Il est compétent. On a soulevé un problème de concurrence faussée qui est totalement de son ressort - et dont un tribunal administratif n'aurait que faire. C'est juste que personne ne s'attendait à ce que les magasin (qui ont juste une autorisation d'ouvrir, pas une obligation (oui dans certaines zones il y a obligation d'ouvrir le dimanche)) choisissent d'ouvrir malgré la décision de justice.
A noter que saisir un tribunal administratif n'aurait pas servi à grand chose - celui-ci aurait probablement juste dit que le préfet a bien le droit d'autoriser des ouvertures le dimanche.
A noter que les magasins prennent un risque, je suis sur qu'il y a pleins de gens compétents dans les hautes sphères judiciaires qui cherchent comment démolir la position de Castorama/Leroy-Merlin. Et si ils ne trouvent pas je prédis du contrôle URSSAF sévère. Mais la ça fait une semaine que ça dure, et plus le temps passe, plus le gouvernement va être obligé de pondre une nouvelle loi qui clarifie la situation pour ne pas désavouer une des grandes institution française (personne n'a envie du dire que la préfecture est plus forte ou moins forte que le tribunal de commerce). Clarifier la situation c'est typiquement ce que Bricorama veut (et probablement Castorama et Leroy-Merlin aussi).
# Hors de question !
Posté par Kaane . En réponse au sondage Ce que je souhaiterais voir disparaître de LinuxFr.org.... Évalué à 10.
Comme tout bon français, j'ai regardé les résultat avant de voter - et là horreur, Patrick_G est moins impopulaire que la tribune (2 vote pour lui, contre trois pour la tribune).
Je en pouvais pas laisser faire ça, et j'ai donc voté Patrick_G.
[^] # Re: 56%
Posté par Kaane . En réponse au journal Travail dominical. Évalué à 4.
Je suis assez surpris. C'est une hiérarchisation qui ne me semble pas intuitive. Il me semble que la loi est au dessus des décrets préfectoraux, le juge ne faisant qu'appliquer la loi.
Tout d'abord le préfet n'est pas au dessus des lois, c'est bien entendu la loi qui permet au préfet de délivrer les autorisations d'ouverture le dimanche.
Ensuite il existe de nombreuses instance judiciaire qui peuvent claquer le beignet du préfet si celui-ci va trop loin - mais ce sont des tribunaux administratifs (le conseil d'Etat a tout pouvoir pour broyer du préfet par pack de douze si il lui en prend l'envie).
Là c'est le tribunal de commerce (je pense, l'information est difficile à valider sur le net) qui interdit une chose que le préfet a autorisée. Comme seul un tribunal administratif peut invalider un arrêté préfectoral, les magasins décident de passer outre.
J'espère que le journal d'un avocat se chargera de m'expliquer ça dans le détail :)
Ça serait bien en effet. Mais c'est rare que Eolas s’intéresse à ce type de sujet.
[^] # Re: 56%
Posté par Kaane . En réponse au journal Travail dominical. Évalué à 5.
Et si le préfet ne respecte pas la Loi et délivre des autorisations bidons, on envoie l'armée?
Techniquement oui. La gendarmerie, qui fait partie de l'armée peut être mise à disposition du préfet - mais n'est jamais aux ordres du préfet. Donc on peut imaginer que le gouvernement fasse envoyer la gendarmerie pour contrer le préfet, mais bon ça sera toujours plus rapide de le destituer et de le ramasser avec des méthodes classiques une fois qu'il a perdu son mandat. (Méthode classique qui peut impliquer la gendarmerie, suivant le lieu d'ailleurs)
Ceci dit, le préfet ne peut pas délivrer d'autorisations bidons - parce que justement c'est le coup de tampon de la préfecture qui valide les autorisation.
Dans le domaine des braderies et liquidations de stock, il y a un cadre légal très strict (un magasin ne peut pas se mettre en braderie tout le temps, les magasins d'alimentaire ne peuvent pas liquider les stocks, les produits achetés récemment doivent être retiré des liquidations ou des braderies etc.) Donc dans le cas d'une liquidation par arrêté préfectoral (suivant la formule consacrée) le préfet peut outrepasser son mandat et délivrer des autorisations qui sont contraire à la loi.
Mais dans le cadre d'une ouverture le dimanche, il n'existe pas de limitations autre que le fait que le préfet doit faire attention à ne pas fausser la concurrence. En d'autres termes si dans sa préfecture il y a plusieurs magasins similaires il n'a pas le droit d'en autoriser certains à ouvrir, mais pas d'autres.
Sauf que bien sur au niveau légal il existe pleins de magasins qui ont le droit d'ouvrir le dimanche automatiquement ou presque (si vous êtes dans une zone très touristique, si vous êtes proches d'un monument historique ouvert au public, si vous êtes dans certaines zones commerciales, si le dimanche est un jour de marché d'une certaine ampleur, si votre activité est fortement lié à celle d'un autre magasin qui a le droit d'ouvrir le dimanche etc.) Donc de base la concurrence est déjà faussée, parfois même volontairement pour attirer des enseignes dans un lieu délaissé des commerces.
Dans le cas de Paris et de la proche banlieue - ou on peut changer de sous préfecture en faisant 100m dans n'importe quelle direction ou presque, les enseignes qui sont situé 100m trop à gauche et qui doivent fermer le dimanche trouvent la blague saumâtre, vu que de l'autre coté du pont leur concurrent direct peut ouvrir.
C'est exactement ce qui a poussé Bricorama a porter plainte.
[^] # Re: 56%
Posté par Kaane . En réponse au journal Travail dominical. Évalué à 9.
Oui c'est dingue que des gens demandent à ce que la loi soit respectée.
Comme par exemple dans le cas de Leroy Merlin Ivry, l'accord de la préfecture non qui les autorise à ouvrir le dimanche pendant encore 6 mois ? Ou encore le magasin de Sainte Geneviève des Bois qui a son autorisation d'ouvrir depuis des années - autorisation qui a été renouvelée en mai ?
Le truc légal ici c'est qu'il s'agit d'un combat entre l’exécutif et le judiciaire, la préfecture et le tribunal de commerce pour être exact, le tout à cause d'un flou assez vaste laissé par le législateur. Tous les magasins qui ouvrent sont dans la légalité. Pour être caricatural il s'est passé ceci :
a) Les magasins n'ont pas le droit d'ouvrir le dimanche
b) La préfecture donne explicitement le droit d'ouvrir le magasin bien que ce ne soit pas autorisé normalement
c) imbroglio juridico-syndical, le juge rappelle aux magasins qu'ils n'ont pas le droit d'ouvrir le dimanche
d) Les magasins répondent qu'ils sont au courant, mais qu'ils ont une autorisation de la préfecture qui les autorise à ouvrir quand même - dont acte.
Le juge ne peut pas invalider l'autorisation de la préfecture, les magasins disposent donc d'un moyen légal de passer outre toute décision de justice sur la fermeture le dimanche. Grosso-modo ils ont un papier sur lequel il est marqué "même si c'est interdit (d'ouvrir le dimanche), vous pouvez le faire quand même."
Si on ajoute à cela le fait que si le juge veut faire appliquer sa décision de justice "de force", par exemple en envoyant la police fermer le magasin, il devra passer par la préfecture pour mobiliser les agents.
Au fait ça n'a rien à voir, mais le mouvement n'a pas été initié du tout par les syndicats (qui cherchent juste à attraper la balle au vol) - mais par Bricorama, qui lui n'avait pas toutes les autorisations nécessaires et a donc été contraint de fermer (ou de modifier ses horaires) le dimanche. C'est lui qui a porté plainte - les enseignes ayant des produits et services similaires, la concurrence est faussée si l'une peut ouvrir et pas l'autre.
[^] # Re: Liberté du renard dans le poulailler?
Posté par Kaane . En réponse au journal Travail dominical. Évalué à 0.
Tu ne réfléchis pas bien: le but des magasins est de passer d'un travail bien rémunéré le dimanche pour certains à un travail pour tous le dimanche payé une misère.
Ah bon ? C'est pas pour le droit d'ouvrir le dimanche quitte à payer de gros suppléments aux salariés parce que 40% du chiffre d'affaire est concentré sur le dimanche. Mince j'ai encore du me tromper d'univers ce matin en me levant.
[^] # Re: travail hebdomadaire
Posté par Kaane . En réponse au journal Travail dominical. Évalué à 1.
Si le choix des salariés était réel, ça ne me poserait pas de problème. Il ne faut pas rêver, il ne l'est pas.
Donc comme les salariés ne pourraient pas choisir de travailler le dimanche librement, on va les forcer à ne pas bosser le dimanche ce qui est tout de suite beaucoup plus respectueux de leur libertés.
Donc comme les syndicats sont incapables de faire leur boulot (comme par exemple en empêchant des abus de se créer sur le travail du dimanche), on va les laisser faire leur boulot (comme par exemple en bloquant le travail le dimanche).
Donc comme les gens pauvres, précaires ou peu diplômés sont vulnérables et sont prêt à tout pour gagner quelques sous et améliorer leur quotidien en travaillant le dimanche, on va éviter que l'on puisse les exploiter facilement en leur fournissant du travail le dimanche - et surtout laisser leur quotidien comme il est (c'est pour leur bien en fait).
Merci de ne pas tomber dans la condescendance.
Qui pense que les salariés sont trop bête/trop mal informés/trop aveuglés par le court terme pour prendre une décision lucide vis à vis de leur dimanche ?
Qui estime que les patrons sont des créatures viles contre lesquelles les malheureux quidam inconscient et naturellement sans défense doivent être protégés ?
Qui assène que si l'on commence à aller dans cette direction, on ne pourra plus jamais faire machine arrière, que l'on aura jamais la force de se mobiliser et d’empêcher un glissement progressif vers les trois huit pour tout le monde, samedi dimanche inclus ?
La condescendance on se la frappe de plein fouet de la par des "anti travail le dimanche".
N.B : Je ne suis pas particulièrement friand du "travail le dimanche" notamment parce que la raison pour laquelle cela fonctionne financièrement est justement parce que 90% des gens ne travaillent pas le dimanche. Mais dans le cas de l'industrie de loisir (à laquelle appartient indubitablement le bricolage) il convient d'avoir une vraie réflexion sur les aménagements possibles d'horaire et les compensations financières des gens qui travaillent le dimanche.
[^] # Re: La cohérence entre les applications ?
Posté par Kaane . En réponse à la dépêche GNOME 3.10 : chantier public. Évalué à 5.
En lisant l'article, j'ai vu que la quasi totalité des applications sont écrites dans des langages différents. Une en Python 3, une en javascript, une en Vala et le reste de GNOME est souvent en C et Python 2.
Ben à la base Gnome c'était un environnement de bureau. Avec le passage à Gnome3 on a commencé à glisser doucement vers l'OS (la quantité de composants systèmes bas niveau dont Gnome3 a absolument besoin est tout simplement effarante). Gnome 3.10 n'est juste que la première mouture de la "distribution" Gnome pour l'OS Gnome 3. Je dis distribution parceque tous les ingrédients sont réunis - gestionnaire de package, mise à jour, interdépendance forte des composants qui doivent être compilés de façon uniforme, choix des outils systèmes etc.
On glisse encore un peu et le concurrent de Gnome 4 ca ne sera pas KDE ou XFCE mais Debian…
[^] # Re: ATTENTION !!!
Posté par Kaane . En réponse à la dépêche PostgreSQL 9.3. Évalué à 4.
Pas d'accord: Il y en a d'autre mais pas forcément dans le monde SQL ;)
PostgreSQL est aussi une excellente base de données hiérarchiques et un très bon datastore clef/valeur.
[^] # Re: taux de reussite
Posté par Kaane . En réponse au journal [ HS ] 10.000 Français se suicident chaque année. Évalué à 10.
il serait pas temps de faire un howto ?
Il est déjà sorti, mais il a été censuré par le pouvoir en place qui lutte activement contre la progression de la connaissance libre, gratuite, internationale et sans contraintes.
http://fr.wikipedia.org/wiki/Suicide,_mode_d%27emploi
# ATTENTION !!!
Posté par Kaane . En réponse à la dépêche PostgreSQL 9.3. Évalué à 10.
Je suis un grand fan de PostgreSQL et il n'y a jamais eu aucun problème de mise à jour avec PostgreSQL MAIS ce coup ci le modèle de mappage mémoire a été modifié. C'est une excellente nouvelle parceque ca va éviter à tous les admins de régler leur shmax aux petits oignons pendant des jours, mais ca implique aussi qu'il y a potentiellement des bugs vicieux qui peuvent se rpoduire sur certaines configs.
A garder un bon moment en test avant de migrer donc.(Plus que d'habitude en tout cas).
Ceci dit ça n'enlève rien à ce qui est le meilleur framework de données
libreau monde.[^] # Re: Tout va bien, je t'assure
Posté par Kaane . En réponse au journal Les BSD isolés. Évalué à 2.
Tu te focalises sur la gestion des personnes alors que ce qui est important c'est la gestion des briques et de leurs interactions.
Bon apparemment je ne dois pas parler en français. Je vais donc être clair, au risque de paraitre un peu vulgaire :
Dans le cadre de cette discussion, qui porte sur la sécurite je me FOUS COMPLETEMENT de l'aspect gestion de projet.
Voilà. Est-ce clair ? Je sais très bien gérer un projet merci.
Mais même si les VCS c'est bien, même si ca permet de faire pleins de choses, même si ca apporte énormément en terme d'organisation etc. Ca n'apporte rien au niveau sécurité.
C'est comme les duplications et les sauvegardes - ca n'a rien à voir. Ca ne veut pas dire que les duplications soient meilleures que les sauvegardes, ou que les sauvegardes sont au dessus des duplications - ca n'a juste **AUCUN RAPPORT*
Ben les VCS et la sécurité c'est pareil. Les ACL apportent de la sécurité, les VCS non. Ce qui ne veut absolument pas dire que l'on peut remplacer les VCS par des ACL. Ce sont deux choses distinctes.
Mais la justification utilisées me laisse très perplexe. Vérouiller qui fait quelle modification sur la prod avec une granularité fichier/rep ca sent pas bon du tout. L'info du mec qui a fait le changement devrait être perdu depuis longtemps entre le VCS, le packaging et le déploiement et ce n'est pas là qu'il faut s'en soucier.
Je te rassure, je ne fais absolument pas comme ça. Je vérouille au niveau fichier/repertoire par mission. Chaque mission correspond à un groupe au sens Unix, et chaque groupe a ses propres ACL. Et mon VCS/packageur/script Node et j'en passe n'appartienent à aucune mission et n'ont aucun droit pour faire la moindre modif sur le système. Ils assument les droits utilisateurs qui sont donnés par la mission de l'utilisateur.
En espérant avoir été clair ce coup ci.
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . En réponse au journal Les BSD isolés. Évalué à 4.
Tout d'abord un grand merci de m'expliquer ce qu'est un VCS quand j'explique depuis maintenant 5 posts que la question posées n'a rien à voir avec les VCS.
Je sais ce qu'est un VCS, comment on s'en sert, je les utilises quotidiennement (et plutôt deux fois qu'une vu que le backup des systèmes est aussi un VCS sur mes machines), je fais du centralisé aussi bien que du distribué etc.
Donc tu as fait des handbook pour le FreeBSD ? Très bien. Estc-e que les modifications que tu as faites se sont retrouvées automatiquement en ligne ?
Non hein ?
Ben voilà.
Maintenant on se moque que ce soit l'admin FreeBSD himself en personne, ou une personne qui qu'elle soit qui a les droits d'administration d'un projet (Hint : il n'est pas forcément root sur tout le domaine) qui ait fait le taf. La sécurité dans les projets FreeBSD vient de la validation humaine. Rien ne se fait sans validation humaine si le mec qui soumet des modifs n'a pas les droits de commiter (i.e : il est probablement pas "stagiaire").
Après comme tu le dis très bien quand il y a 200 briques projets, des centaines de milliers de lignes de codes sur des sujets aussi variés que les I/O bas niveau et les CSS level3 compatibles IOS, c'est rarissime d'avoir assez d'admins (i.e chef de projets/commiteurs/responsables etc. par forcément des mecs root) pour faire une validation manuelle et fiable de tout ce qui passe. C'est ce que je soulignais en disant "L'admin va probablement trouver la blague saumâtre".
Et les VCS n'aident absolument pas à résoudre les problèmes de sécurité qui se posent.
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà… Ce n'est pas la bonne réponse.
Avec les ACL le mecs ne peut effacer que les fichiers sur lesquels il a les droits. Donc le mec peut lire le code HTML, mais n'avoir le droit que de modifier certains fichiers CSS. Alors que les fichiers sont lisibles aussi bien par le proxy nginx que par apache et qu'un autre stagiaire ne peut modifier que les fichiers images.
Sans ACL (et sans MLS/MAC ) forcément, il faudra mettre des droits inutiles à un des uid qui écrivent ou lisent sur le disque. Peut importe que ce soit l'uid du VCS, d'apache ou de nginx. Les fichiers ont un propriétaire et un groupe - avec à chaque fois un seul set de droits. Forcément tu augmentes la surface d'attaque en conservant les droits Unix plutôt qu'en mettant des ACL bien foutu. Et peut importe que ce soit le stagiaire, le VCS, Apache, ou nginx qui ait trop de droits (ie accès à des fichiers auquel il ne devrait pas avoir accès) ca pose un problème de sécurité qui est ultra-simple à résoudre.
Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis.
Non. Elle va livrer des artefacts dans une section artificiellement restreinte d'un contexte beaucoup trop large - et on reporte sur le processus de déploiement la charge de limiter, via du code userspace, la zone d'impact de ce déploiement.
La surface d'attaque est l'ensemble de tous les répertoires que l'utilisateur (au sens uid) VCS peut lire ou écrire. Sans ACL cette surface est disproportionnée par rapport au besoin.
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . En réponse au journal Les BSD isolés. Évalué à 4.
On se moque que ce soit relié directement ou indirectement à la production. Le stagiaire a les droits sur le serveur et basta.
C'est amusant cette façon que vous avez tous de confondre organisation et sécurité - surtout dans un thread qui est centré sur les access control.
Peut importe que le chemin soit tortueux, passe par trente applis qui redistribuent les fichiers dans tous les sens et que quinze procédures de vérifications automatiques se déclenchent - la question est "le stagiaire peut-il créer des fichiers sur un répertoire situé sur le serveur sans l'intervention d'un admin ?". Si la réponse est oui, le stagiaire a les droits sur le serveur. (Et si la réponse est non - il y a des admins qui doivent sérieusement trouver la blague saumâtre).
Je ne remets pas en cause les avantages d'un VCS, mais il faut bien se rendre compte qu'un VCS est un outil d'organisation, pas de sécurité - même avec un VCS, même avec un système très complexe de validation automatique, le stagiaire a toujours les droits sur le serveur. Ca ne veut pas dire qu'il a un uid qui peut se loguer sur le serveur et écrire dans un répertoire directement - ça veut dire qu'il fait une manip sur une machine et que quelques temps plus tard un fichier sur le serveur est créé/modifié/supprimé.
Les VCS permettent de s'organiser pour éviter les accidents et pouvoir revenir facilement en arrière au cas ou un accident se produit quand même. Mais ils apportent 0 au niveau sécurité.
Et quand le stagiaire a besoin de pouvoir écrire (même indirectement) sur un répertoire qui doit être lisible par Apache mais pas par le monde entier, on se retrouve très vite limité avec les droits Unix standard - sur toute machine (même mono utilisateur) les ACL devraient être activés par défaut sur toutes les partitions, et l'admin ne devrait les éteindre que si il a une excellente raison de le faire. Ce n'est pas le cas aujourd'hui.
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . En réponse au journal Les BSD isolés. Évalué à 2.
Le stagiaire peut (et doit) commiter dans le VCS…et n'a même pas d'accès au serveur
Le stagiaire a accès à un truc qui accès au serveur ("un truc" pouvant être composé de milliers de programmes à la queue leu leu).
Donc le stagiaire a des droits sur le serveur.
Le truc qui va écrire au final sur le disque dur du serveur (via deb, rpm, shadow copy etc.) doit avoir des droits sur le répertoire cible sur le serveur. Avec des ACL on peut limiter la surface d'attaque - avec des droits unix de bases on ne peut pas avoir des groupes qui ont des droits en lecture, d'autres qui ont des droits en écriture etc. et on se retrouve systématiquement à donner plus de droits qu'il n'en a besoin au stagiaire (Même si c'est au travers de 112 000 outils).
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . 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.
Unification et coté monolithique n'ont pas grand chose à voir. C'est très bien que SELinux unifie les politiques d'accès (sans ironie hein), mais c'est un peu domage de devoir mettre en place tout le framework de a à z pour une politique de 3 lignes. J'ai bien conscience que vu la nature et les ambitions de SELinux il n'est pas possible de découper le framework en pleins de petits morceaux utilisables séparément, mais je préfère quand même l'approche biba de FreeBSD.
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Sur quelle distribution ? Parceque si les outils pour les ACL sont intégrés, c'est rare que les FS aient les ACL activés par défaut. Je change pas de sitrib tous les deux jours, mais l'année dernière il n'y avait guère que Suse et Fedora qui activaient les ACL par défaut.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça.
Tout simplement faire démarrer un service en écoute sur un port local non privilégié et rajouter une règle firewall pour faire le lien. Ca évite de devoir lancer tout un tas de service en utilisateur root (même si après les privilèges redescendent - c'est quand même pas top).
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.
Même avec un VCS, à un moment ou à un autre il va bien falloir aller écrire dans /var/www (ou autre répertoire) et là sans les ACL tu as deux solutions : soit tu donnes le groupe www a tous les utilisateurs susceptible de devoir modifier le site (ou faire un commit si tu préfères), soit tu ajoutes l'utilisateur apache dans 200 groupes.
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 ).
Alors distinguons bien deux cas :
a) Il s'agit d'un utilisateur avec un compte et un uid qui est logué en console et qui utilise, par exemple, psql - et là avec les labels multiples le mec il peut toujours se brosser pour accéder au contenu d'un tablespace qui n'est pas autorisé. (Je pensais que tu parlais de ce cas là)
b) Il s'agit d'un utilisateur logué à distance (par exemple sur le port 5432 via réseau) - et là de toutes les façons les accès se font via le serveur, sous l'uid du serveur. La seule chose qu'apporte SE-Postgres dans ce cas c'est que les restrictions et les droits ne sont plus validé seulement contre le système interne à Postgres mais aussi vis à vis d'un jeu de police de sécurité SELinux. Cependant si le plugin est compromis (ce qui implique qu'il n'était pas lui même protégé par une policy - ce qui serait idiot je l'admet) SE Linux ne verra rien passer des requètes faites à PostgreSQL.
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.
La question est de quoi ai-je besoin pour faire confiance à l'autre machine ? Si c'est juste tester la présence d'une clef ipsec est très bien dans le rôle, si j'ai besoin de plus que ça il faut que je sache le valider chez une machine tiers. A aujourd'hui si j'ai besoin de plus que la présence d'une clef privée, il faut que je maintienne le serveur complètement - ce qui peut être lourd. CIPSO était supposé répondre à ce problème - on devait être capable de s'envoyer des paquets certifiés qui anoncnet que le serveur distant est bien en train de faire tourner un apache à jour avec mod_rewrite désactivé, que le routeur machin droppe les paquets DHCP ver telle ou telle branche réseau, que les url de type xxx://#!!%/*.truc sont interdite etc.
Est-ce que aujourd'hui c'est possible vis à vis d'une machine que je n'administre pas ? Oui/partiellement/non ?
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . En réponse au journal Les BSD isolés. Évalué à 8.
proche, tu veux dire "si on rajoute les trucs manquants"
Non par proche je veux dire "Dans le même esprit que". C'est clair que SELinux fait pleins de choses que MAC ne fait pas, et que MAC avec les jails fait des trucs que tu peux imiter avec SELinux+OpenVZ - mais tu vas y passer un moment quand même.
Maintenant SELinux est ultra monolithique dans son approche. Chez FreeBSD tu vas avoirs plusieurs outils pour arriver grosso modo au même résultat.
C'est vrai que SELinux a une granularité plus fine que MAC (nettement) - mais c'est vraiment trop lourd à mettre en place et à maintenir.
et "si on code une policy, parce c'est tellement simple que personne commence, sauf des boites qui gardent ça pour elle grace à la license BSD" ?
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 ? 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….
Parmi les trucs manquants, tu peux mettre des labels sur les bases postgresql, sur les paquets réseaux via CIPSO ( notamment utilisé par openshift afin de sécuriser les échanges entre containers ), ou directement sur X.
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.
En ce qui concerne CIPSO j'ai décroché depuis 2007 environ. Je ne sais pas du tout ou ca en est. En 2007 ils relancaient une grosse phase de draft, la 42ième depuis 1990. On a tenté de mettre en place un truc de tests pour des échanges en trusted Solaris et NetLabel. Ben plouf. Une recherche rapide sur internet me donne une page blanche à l'IETF et deux liens de 2006 sur les NetLabels Linux. En insistant un peu on trouve trois lignes dans un article Wikipedia sur Solaris. Vrai question : "C'est utilisé ce truc là ?" (Attention par utilisé je veux dire est ce que l'on arrive à faire négocier ensemble des machines qui n'ont pas la même version du kernel redhat, avec les policy redhat et tout le toutim - si ca permet juste à deux machines configurées à l'identiques par un admin unique de dialoguer de façon sécure c'est moyennement interressant)
------------------------------------------------------------------------------ SNIP
Pour en revenir au sujet de mon post, j'ai comparé les MAC BSD à du SELinux juste pour bien expliquer que FreeBSD a mieux que les cgroups en stock. C'est très largement possible de faire tout ce que font les cgroups avec MAC dans le cadre d'un portage systemd - surtout vu la façon assez légère dont les cgroups sont utilisés par systemd.
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . En réponse au journal Les BSD isolés. Évalué à 9.
Awé ? I need explanations! (ce n’est pas ironique).
Dans les MAC il y a à peu près tout ce que font les CGroups et bien plus. On a du partitionnement, de la délégation de privilège, de l'isolement, de l'héritage de droits etc.
Pour faire court, il y a dans FreeBSD un système qui est proche de SELinux niveau fonctionnalité, mais nettement plus utilisable et lisible.
Ensuite le système d'init lui même n'est pas sysV - Il s'agit de l'init BSD historique - en l'occurence RC - Dont la conversion vers un système type upstart/systemd serait très simple. Les fichiers RC sont déjà très très normés, les places pour les différents éléments sont connus etc. Il faut bien voir que les *BSD ne fournissent pas un kernel mais tout un OS - de fait il n'y a qu'un seul système d'init et un seul groupe qui le maintien. Le bazar que l'on a eu au niveau des inits Linux ne s'est jamais vraiment produit sous BSD.
Il existe tout un tas d'init alternatifs qui fonctionneraient très bien sous FreeBSD si ons se donnait un peu de mal (OpenRC par exemple).
Après malgré la facilité qu'il y aurait à changer le système d'init et le fait que le système posséde depuis des années des utilitaires éprouvés pour faire tourner la nouvelle solution (certaines opérations sont déjà asynchrone au boot depuis des lustres) - ben personne de sérieux ne voit l'intéret de s'y mettre. En l'état actuel de qualité du rc, un changement permettrait peut-être de gratter une dizaine de secondes au boot (dans certaines conditions très particulières - pas de DHCP ou de firmwares à charger par exemple) mais n'aurait pas d'impact majeur. Le point le plus interressant étant ce que ça pourrait apporter à une machine avec beaucoup de jails qui tournent…
Pour une longue discussion sur le sujet en Anglais http://lists.freebsd.org/pipermail/freebsd-hackers/2012-June/039287.html
(Attention les experts systèmes arrivent un peu tard sur le thread, prendre les 10 premiers posts avec des pincettes).
# Tout va bien, je t'assure
Posté par Kaane . En réponse au journal Les BSD isolés. Évalué à 10.
On se rend donc compte que les BSD sont en train de se faire dépasser par le Hurd, ce qui est un peu la honte.
Non, non. Tout est OK. BSD possède tous les outils nécessaires pour implémenter un init façon systemd très facilement. Regarde simplement du coté des MAC de FreeBSD par exemple.
Donc si un jour il y a vraiment obligation d'avoir un truc similaire, on l'aura très très vite sous BSD.
[^] # Re: PulseAudio mais je n'aime pas Lennart
Posté par Kaane . En réponse au sondage Votre solution pour le son. Évalué à 1.
En fait, quand c’est pas assez intégré on râle, si c’est trop intégré on râle.
Le problème de systemd c'est pas son integration, c'est la liste importante de choses que tu ne peux plus faire. Les daemon mono-processus par exemple sont ingérables, one ne peut plus passer de variabales d'environnement ou de paramètres aux services de façon dynamique. Le service A ne peut plus demarrer le service B sans passer par systemd - ce qui ne peut se faire que si le service A a des droits monstrueux. Et il y en a comme ça une pelletée.
[^] # Re: PulseAudio mais je n'aime pas Lennart
Posté par Kaane . En réponse au sondage Votre solution pour le son. Évalué à 2.
Ce n'est pas une couche en plus. On peut utiliser journald tout seul.
Non. C'est totalement impossible et assumé par Lenart. Journald ne sait discuter qu'avec systemd dans un environement (structure du file system, variables de kernel, outils d'interaction etc.) prévu pour.
La compatibilité syslog, c'est juste de la rétrocompatibilité et pour ceux qui préfèrent les logs en texte (même si journald fournit de quoi filtrer ses logs et sort du texte sur la sortie standard quand on appelle journalctl). Bref, c'est totalement inutile dispensable.
Oui, déjà il faut aimer les logs textes passés par la moulinette journald, et ensuite le mec qui a son journal binaire corrompu pour une raison X ou Y, il fait quoi ? Ben généralement il est super content d'avoir les vieux logs textes totalement dispensables - mais lisibles eux.