Nous proposons un module qui permet de se passer des commandes su et sudo. L’avantage de notre module est qu’il permet de contrôler la liste des privilèges donnés aux programmes.
Traditionnellement, l’administration des systèmes GNU/Linux repose sur l’existence d’un seul utilisateur puissant (appelé super‐utilisateur) qui détient à lui seul la liste complète des privilèges du système. Cette vision a été critiquée car tous les programmes exécutés dans le contexte du super‐utilisateur obtiennent beaucoup plus de privilèges qu’ils n’en ont besoin. Par exemple, tcpdump demande uniquement le privilège cap_net_raw pour s’exécuter. Cependant, en l’exécutant dans le contexte de super‐utilisateur, tcpdump obtient la liste complète des privilèges du système. Ainsi, l’approche traditionnelle de l’administration GNU/Linux rompt le principe du moindre privilège, qui garantit qu’un processus doit juste avoir les privilèges nécessaires pour effectuer son travail. Un attaquant pourrait exploiter les vulnérabilités de tcpdump afin de compromettre la sécurité du système.
Il existe cependant une autre voie, non officielle, mais intégrée au noyau Linux depuis 1998…
Un brouillon POSIX (POSIX draft 1003.1e) avait été proposé afin de définir un modèle qui permet de donner aux processus uniquement les privilèges de super‐utilisateur dont ils ont besoin. La proposition définit pour chaque processus trois ensembles de bitmaps appelés Inheritable (i), Permitted (p) et Effective (e). Ce modèle n’a pas été adopté officiellement, mais il a été intégré au noyau Linux depuis 1998.
Cependant, pour différentes raisons, ce modèle n’a pas été largement utilisé :
- Premièrement, le modèle de capacité de Linux présente différents problèmes techniques en raison de l’utilisation d’attributs étendus pour stocker les privilèges dans les exécutables (problème 1).
- Deuxièmement, les administrateurs de systèmes GNU/Linux ne disposent pas d’un outil leur permettant de distribuer les privilèges aux utilisateurs de manière fine (problème 2). La distribution fine de privilèges devrait donner aux administrateurs la possibilité de décider quels privilèges accorder aux utilisateurs, quels programmes (par exemple,
tcpdump) peuvent utiliser ces privilèges et sur quelles ressources ces privilèges peuvent être appliqués (par exemple, interface réseau eth0). - Troisièmement, GNU/Linux ne fournit pas d’outil permettant aux utilisateurs de connaître le privilège demandé par une application (problème 3).
- Quatrièmement, GNU/Linux est livré avec des commandes de base qui ne sont pas compatibles avec des privilèges, tels que la commande
passwd(problème 4).
En conséquence, la majorité des utilisateurs de GNU/Linux utilisent toujours les commandes su et sudo pour exécuter des applications privilégiées, car le modèle super‐utilisateur présente l’avantage d’être facile à utiliser.
Récemment, un nouvel ensemble de privilèges appelé Ambient a été intégré au noyau Linux afin de résoudre les problèmes techniques liés au stockage des privilèges dans les attributs étendus des exécutables. Cependant, le système GNU/Linux ne fournit pas de solutions pour gérer les problèmes deux et trois.
Le module RAR (Root As Role) implémente une approche basée sur les rôles pour distribuer les privilèges aux utilisateurs. Il fournit une solution au problème deux : notre module est livré avec un outil appelé sr (switch role) qui permet aux utilisateurs de contrôler la liste des privilèges qu’ils accordent aux programmes.
Ainsi, avec notre module, les utilisateurs de GNU/Linux peuvent cesser d’utiliser les commandes sudo et su, qui ne permettent pas de contrôler la liste des privilèges à donner aux programmes.
Il existe déjà des outils permettant de contrôler la liste des privilèges à attribuer aux programmes tels que setcap et le module pam_cap. Cependant, ces outils nécessitent l’utilisation d’attributs étendus pour stocker les privilèges. Or stocker des privilèges dans des attributs étendus pose de nombreux problèmes. Notre module permet d’attribuer les privilèges Linux sans avoir besoin de les stocker dans les attributs étendus des fichiers exécutables.
Grâce à ce module, les administrateurs peuvent regrouper les privilèges Linux dans des rôles et les donner à leurs utilisateurs. Pour des raisons de sécurité, les utilisateurs n’obtiennent pas les rôles attribués par défaut, ils doivent les activer à l’aide de la commande sr (changer de rôle).
Notre module est compatible avec pam_cap.so, les administrateurs peuvent donc continuer à utiliser pam_cap.so avec lui.
Concrètement, notre module permet de respecter le principe du moindre privilège en donnant aux utilisateurs la possibilité de contrôler la liste des privilèges qu’ils accordent à leurs programmes.
Le code (GPL v3) et des exemples plus complets sont disponibles sur la page GitHub du projet.
Aller plus loin
- RAR module (949 clics)
# Demande de compléments
Posté par feth . Évalué à 5.
Merci pour ces explications claires mais qui appelleraient quelques compléments et un peu de mise en page, et surtout merci de ce travail.
Il y a des exemples et des explications vraiment apétissantes (que je n'ai pas encore eu le temps de lire) qui permettent de mieux comprendre l'usage de l'outil sur la page github que vous mettez en lien.
Pouvez-vous expliciter qui est le «nous» de la première phrase (personnes, organisation…) et si vous faites ça sur votre temps libre, ou si vous vendez du conseil etc ?
Merci encore !
[^] # Re: Demande de compléments
Posté par guildem . Évalué à 9. Dernière modification le 06 septembre 2018 à 11:31.
J'ai lu le Github, c'est bien plus explicite que ce post (mais bon merci pour le post hein, ça m'a permis de découvrir cette fonctionnalité perdue et ce projet très intéressant !).
L'équipe y est détaillée :
Et les exemples sont bien détaillés et donnent plein d'infos sur le sujet.
Je pense que tu y trouveras tes réponses.
[^] # Re: Demande de compléments
Posté par samerw . Évalué à 9.
Bonjour,
Je vous remercie pour votre commentaire.
"nous" c'est mes collègues et moi-meme qui ont participé à ce travail. Ce travail est le fruit d'un travail de recherche à l'université de Toulouse.
[^] # Re: Demande de compléments
Posté par ZeroHeure . Évalué à 4.
Votre modérateur bienveillant du jour a refait la mise en page.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Demande de compléments
Posté par BAud (site web personnel) . Évalué à 2.
mici _o/
tu remplaces Oumph< ponctuellement ?! (oui ça s'est vu \o/ et pas qu'une fois)
# Petite question ...
Posté par Christophe B. (site web personnel) . Évalué à 3. Dernière modification le 06 septembre 2018 à 11:36.
Bonjour,
Donner des privilèges à un executable pourquoi pas …
Récemment j'ai testé l'attribution de privilèges à cause du fameux Selinux pour un cas tout simple concernant apache
C'est une commande a noter quelque part ok … mais le problème c'est que cela semble lié à l'éxécutable
et que si pour une raison cet éxécutable change, pour une mise a jour par exemple les privilèges deviennent caduques
Et cela ne marche plus … tant que l'on a pas remis les privilèges (la fameuse commande)
Même si c'est logique, cela peut devenir vite contraignant et alourdir la procédure de mise à jour qui dans certain cas peut être assez fréquente.
Voila je voulais juste vous sensibiliser sur ce point et savoir ce qu'il en est …
La sécurité à un prix … c'est sur
[^] # Re: Petite question ...
Posté par samerw . Évalué à 2.
Bonjour,
la mise à jour des executables n'est pas le seul problème concernant le stockage des privilèges dans les attributs étendus. Comme précisé dans la page Github, il existe d'autres problèmes comme : executer des scripts privilégiés, LD_PRELOAD et d'autres.
[^] # Re: Petite question ...
Posté par jyes . Évalué à 2.
Ce n’est pas la solution présentée dans cette dépêche. Ici, ce qui est présenté; c’est une alternative à su/sudo qui repose sur les « capabilities » et rend ce mécanisme de sécurité utilisable relativement facilement. C’est justement une réponse aux limitations que tu soulèves (et c’est expliqué dans la dépêche).
[^] # Re: Petite question ...
Posté par samerw . Évalué à 3. Dernière modification le 06 septembre 2018 à 13:25.
En utilisant notre outil, les utilisateurs n'auront pas besoin des sudo et su qui ne permettent pas de controller les privilèges passés aux programmes.
D'autres part, je ne comprends pas quand vous dites "la sécurité a un prix" car notre solution ne diminue pas la sécurité, bien au contraire elle permet de limiter l'usage des privilèges à certaines commandes et encore à certain arguments de ces commandes.
Finalement, je suis d'accord avec vous que la dépêche n'explique pas tout, mais vous pouvez trouver toutes les infos sur la page Github.
Merci
[^] # Re: Petite question ...
Posté par bubar🦥 (Mastodon) . Évalué à 8. Dernière modification le 07 septembre 2018 à 12:03.
Des différents points abordés par plusieurs commentaires, il m'apparait un élément, peut être je me trompe mais je le soumet à la sagacité des autres lecteurs et à la votre :
Il semble qu'il y a une incompréhension dû à l'objectif expliqué :
D'une part cela cause d'un objectif vague, une "réduction de la surface des droits accordés" ;
D'autre part cela cause d'implémentation, et d'autres systèmes ;
Et enfin on revient sur votre postulat de base et votre descriptif d'introduction.
La situation est déjà assez complexe : droits unix de base souvent mal utilisés (il est pourtant simple, par exemple, de ne pas donner un droit de lecture tout en accordant un droit d'écriture, mais ce n'est pas très pratique :p en l'état), attributs étendus (utilisés aussi bien, par exemple, pour le system acl que pour la security selinux), auxquels s'ajoutent parfois les capabilities (pour éviter, par exemple, un bit_suid sur la commande ping). D'ailleurs j'ai une question simple : lors de la création d'un nouveau groupe, comment définit on les capablities qu'on accorde à ce groupe ? :p
Donc si j'ai bien compris votre postulat de base peut être résumé en : «on ne touche presque rien au système existant» (sinon, et si votre objectif avait été la "réduction de la surface des droits accordés", vous auriez peut être procéder autrement en utilisant massivement des combinaisons fines et nombreuses entre des utilisateurs et des groupes pour les logiciels et des acl en plus pour les arborescences, cette solution suffit mais elle nécessite de modifier les post-install des paquets, au final d'entretenir une distrib, presque, mais reste moins couteuse que de modifier les logiciels eux-mêmes tel que le pratique OpenBSD pour aller plus loin). Vous partez du constat de l'existant en matière de distribution, presque tout est root:root pour les logiciels, seuls trois ou quatres binaires ont des cap déclarées, et les programmes plus ou moins bien fait demandent eux mêmes et/ou font de l'abandon de privilèges.
Ce postulat de base est important, primordial, et je ne doute pas qu'il puisse être exprimé autrement, mieux, plus finement, pour dire quelque chose comme "on travaille sur la distrib telle qu'on l'a, et on ne la refait pas".
Ensuite votre introduction peut être résumée en "remplacer sudo par quelque chose qui prenne en charge les possibilités offertes par le système des capabilities", finalement. Et cet angle d'attaque est, je trouve, imho tout ça, particulièrement intéressant, et pertinent.
Vue ainsi cela ressemble à la continuation logique de l'élimination des bit_suid en utilisant les capabilities. Vous le proposez de manière dynamique, sans toucher à la distrib, et facilement configurable.
Critiques générales :
Si le modèle du super-utilisateur est si utilisé c'est parcequ'il correspond au besoin de la plupart des usages, qui restent finalement assez simples. Que cela soit sur un serveur web, un serveur de vm ou un ordinateur personnel, ce modèle simple et loin des possibilités du système suffit pourtant. La crainte est donc que, même avec une certaine simplicité de configuration, cela ne soit pas ou peu utilisé sans proposer des politiques par défaut déjà prêtes (ce que fait, pour un autre objectif et un autre type d'implémentation, firejail, ou encore différent : suricata). Quant à demander d'utiliser une commande préalable à tout autre, cela restreint bien probablement l'usage de
srà quelques environnements multi-utlisateurs / multi-administrateurs où le cloisonnement de responsabilités est primordial. Mais également très intéressant pour un ordinateur personnel, dès lors que des règles sont livrées établies et maintenus (comme le disait Linus : c'est stupide d'être root pour configurer une horloge, une carte graphique ou une imprimante sur son PC personnel) : pour ce cas aussi il y a une voie ..Ces deux critiques posés, il semble nécessaire de répéter que je trouve votre approche de remplacer sudo par un utilitaire de gestion des capablities particulièrement pertinent. Alors une question : qu'est ce qui a fait que vous ayez choisi de développer un module à part plutôt que de contribuer à sudo ? (il n'y a ni malice dans la question, ni bonne ou mauvaise réponse, juste une demande d'info)
Enfin, deux remarques sur le configure et le déclaratif pam : dans le configure il y a un mélange entre dépendances nécessaires à la compilation et post-installation, envisagez vous de séparer les deux ? Par exemple avec un simple readme pour dire ce dont il a besoin, et ensuite une bascule des cp et chmod dans le Makefile ? Ensuite concernant la règle pam : elle n'est pas distro agnotisque, mais elle est très simple donc envisagez vous de la rendre plus générique ? Ces points font qu'en l'état actuel il n'est pas possible d'utiliser immédiatement votre module sur autre chose qu'une Debian. Enfin, vu qu'il a un besoin strict de pam, il ne sera pas possible de l'utiliser sur une Slackware par exemple. Du coup, il serait peut être bien d'ajouter une note à ce sujet car
srn'est pas "pour linux", mais pour une distrib basée sur Debian (pour le moment du moins) et qui a pam.[^] # Re: Petite question ...
Posté par samerw . Évalué à 10. Dernière modification le 07 septembre 2018 à 14:26.
Bonjour,
Je vous remercie pour l'ensemble de vos commentaires très intéressant. Je vais essayer de répondre:
Notre objectif est de donner la possibilité aux utilisateurs de controller les privilèges qu'ils passent aux programmes. Avec notre module en l'état actuel, l'utilisateur doit au préalable connaitre les privilèges demandés par un programme, ensuite définir les roles dans le fichier de configuration et à la fin utiliser sr avec le role défini pour lancer le programme. C'est un peu laborieux, j'accepte. Mais Nous souhaitons faire évoluer notre module pour rendre la tache facile aux utilisateurs. En particulier, nous souhaitons étendre le kernel de Linux pour enrichir la fonction cap_capable dans le kernel. Si vous regardez le code source de cette fonction, vous réalisez qu'il ne fait pas grande chose à part vérifier l'existence des privilèges dans le set effective des processus. Nous souhaitons développer cette fonction pour nous indiquer les privilèges demandés par les processus et les ressources utilisées avec ces privilèges. Quand on obtient cette information nous pourrons alors automatiser le choix des roles pour l'utilisateur. Par exemple, lorsqu'un programme demande l'accès à une ressource privilégiée, cap_capable va nous rendre des informations que nous croisons avec les infos dans le fichier capabilityRole.xml pour indiquer au utilisateur le role qu'il doit utiliser ou définir dans le fichier xml. Nous devons également étudier tous les programmes de bases qui viennent avec Linux et définir des roles basiques qui permettent aux utilisateurs standard d'utiliser ces roles.
Concernant l'amerlioration du sudo, je ne vous pas cache c'était notre volonté au départ. Simplement nous avons changé notre avis car le code sudo est assez compliqué, il nous fallait du temps pour l'étudier correctement et on n'était pas sûr des impacts de modification du code. Du plus, nous avions la volonté de faire un module composé de plusieurs outils. Pour l'instant notre module est composé d'un seul outil, mais nous souhaitons ajouter d'autres outils comme roleadd, rolemodify, sr_admin, etc..chacun de ces outils va avoir un role administratif associé défini par défaut dans le fichier xml.
Concernant l'installation et la configuration, nous allons travailler pour les rendre plus génériques. Un seul problème, il me faut des contributeurs pour améliorer ce travail car je n'ai pas personnellement assez du temps pour finir toutes ces améliorations.
[^] # Re: Petite question ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
La gestion de sécurité est complexe, car on la fait reposer soit sur les exécutables, soit sur des droits de chaque utilisateurs. Cela marche depuis SELinux, mais c'est hyper complexe. Le système de base root/user a le mérite d'être simple à mettre en œuvre.
Je pensais que la modèle de sécurité a été "plié" en utilisant la méthode du moindre privilège : en gros, un exécutable root bien élevé est cessé faire tomber tous les privilèges dont il n'a pas besoin (et ni lui, ni ses enfants ne peuvent les récupérer). Si on reprend l'exemple de tcpdump, avec une telle approche le script obtenu ne serait pas vraiment root.
On peut utiliser aussi ce principe pour lancer des utilitaires "wrappés".
Il y a un gros reproche à faire à tous ses modes de sécurités : souvent il est question de l'intégrité de la machine, mais souvent l'utilisateur s'en fout, il a surtout peur de perdre les 10 ans de photos à cause d'un crypto-locker. Et même un programme ayant simplement l'id de l'utilisateur peut faire très mal.
Je pense qu'il faudrait repenser les "capabilities" en fonction des données utilisateurs qui est finalement ce qu'il le plus de valeurs dans le système (perte de données ou fuite de données).
Si vous arrivez à faire en sorte qu'une faille mozilla soit impossible à utiliser pour sortir des données, le tout sans 3 tonnes de configuration, vous êtes très fort.
"La première sécurité est la liberté"
[^] # Re: Petite question ...
Posté par Psychofox (Mastodon) . Évalué à 4.
Là tu pars du principe d'un os à usage mono-utilisateur.
Dans le cas d'un serveur de fichiers ou un serveur de messagerie, qui peuvent héberger les données de milliers d'utilisateurs, c'est justement critique qu'une attaque ne se propage justement pas d'un utilisateur à un autre.
Donc non ce n'est pas parce que les données utilisateurs ont le plus de valeur qu'il faut laisser tomber toute démarche visant à éviter une escalation de privilèges, bien au contraire. C'est ce qui peut faire la différence entre 1 incident / 1 utilisateur ayant des données à restaurer et toute une infra paralysée, des milliers d'utilisateurs bloqués et tout autant d'appels.
[^] # Re: Petite question ...
Posté par barmic . Évalué à 5.
Je ne connais que le cas de debian, mais c'est quelque chose qui se laisse très bien gérer par le gestionnaire de paquet (au même titre que s'assurer que les fichiers ont le bon utilisateur, groupe et droits).
[^] # Re: Petite question ...
Posté par bubar🦥 (Mastodon) . Évalué à 3. Dernière modification le 06 septembre 2018 à 23:50.
Oui, et si c'est un contexte changé par rapport à ce que le gestionnaire de paquets attends (qu'il lit du spec du paquet), par exemple parcequ'on utilise un endroit non-standard (cas courant avec apache) alors la création d'un module spécifique de règles selinux correspond au besoin : ne plus avoir en s'en occuper.
semanageet zou, simple efficace.On peut scripter aussi, pour mettre des attributs plus cools automatiquement sur l'espace data de nextcloud, par exemple, pour profiter de la mise à jour en "full web", puis remettre tout ça plus correctement après, en automatique.
Et pour démarrer, rien de vaut le retour de logs de setroubles en preprod, il dit quoi faire et comment faire dans 95% des cas, y a plus qu'à pousser en prod. Bref, SElinux c'est pas si compliqué que ça (tant qu'on ne touche pas au :sX ..)
C'est un peu hors-sujet avec la dépêche, cette tirade. Par contre je me demande comment selinux et rar cohabitent. Hop, direction les tests.
# faille tcpdump?
Posté par octane . Évalué à 8.
"Un attaquant pourrait exploiter les vulnérabilités de tcpdump afin de compromettre la sécurité du système."
Même pas besoin de faille dans tcpdump pour accéder à tout le système. On imagine que tcpdump est suid, alors:
$ tcpdump -n -i lo -G1 -w /dev/null -z ./runme.sh
va exécuter le script runme.sh avec les droits root.
Pourquoi? Car tcpdump peut stocker les paquets capturés dans des fichiers (le -w) et éventuellement zipper les fichiers capturé (gain de place) et propose d'utiliser un autre programme de compression que gzip (option -z). tcpdump ne valide absolument pas le programme qui gère la compression, donc là, à chaque rotation de fichier de capture (option -G1 => rotation à chaque paquet capturé), le programme runme.sh est appelé…
Et root access pour tout le monde …
[^] # Re: faille tcpdump?
Posté par claudex . Évalué à 4.
Pourquoi ? Parce que dans ce cas, on peut imaginer que vim ou less sont setuid aussi.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: faille tcpdump?
Posté par octane . Évalué à 5.
Je vais tenter de clarifier mon propos.
L'article parle des capabilities. Et il référence tcpdump comme exemple, en indiquant que tcpdump pourrait avoir une faille.
Je suppose que le raisonnement est le suivant: si un utilisateur du système a le droit de lancer tcpdump et que l'utilisateur lance tcpdump et que tcpdump a une faille alors l'utilisateur peut exploiter la faille pour passer root.
Je dis juste que si un utilisateur a le droit de lancer tcpdump (via sudo, ou le suid), alors l'utilisateur peut passer root, indépendamment d'une faille dans tcpdump.
Le raisonnement est le même avec vim ou less.
[^] # Re: faille tcpdump?
Posté par lolop (site web personnel) . Évalué à 6.
Non. L'utilisation sudo de tcpdump peut être restreint dans le fichier sudoers afin que l'utilisateur X puisse en effet lancer
sudo tcpdump(qui sera donc exécuté en tant que root), mais pas d'autre commande. L'exemple de faille donnée est basé sur le fait que tcpdump peut lancer un autre binaire (de compression) qui héritera des droits de root et pourra alors faire tout ce qu'il veut.Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: faille tcpdump?
Posté par Alex G. . Évalué à 4.
Yes ça me rappelle une (grosse) boite où j'ai bossé et qui pour permettre d'accéder à un fichier de log sur AIX avait utilisé "sudo vim /le/fichier.log" (bon c'était pas en root, mais un membre du groupe admin). Ils avaient bien fixé ça comme seule commande, en passant complètement à coté du fait que l'utilisateur pouvait lancer des commandes depuis vim ! (bon je leur ai quand même dit :-D)
[^] # Re: faille tcpdump?
Posté par chdorb . Évalué à 1.
On a peut-être bossé pour la même grosse boîte. J'ai eu un même cas similaire, quelques commandes autorisées dans /etc/sudoers dont vim. Du coup, vim, :!/bin/sh et hop un shell en root :-)
[^] # Re: faille tcpdump?
Posté par claudex . Évalué à 7.
Je la connais avec un équipement propriétaire qui te demande d'accepter la licence avec un less lancé en root.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: faille tcpdump?
Posté par claudex . Évalué à 8.
Je pense que ce n'est pas le bon raisonnement dans ce cas. Et je pense qu'il s'agit du suivant:
Tu lance tcpdump en root (par simplicité) et s'il a une faille, un pirate qui t'enverrait du trafic à ce moment là peut avoir accès à toute la machine alors que s'il n'avait que net_cap, il serait beaucoup plus restreint.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: faille tcpdump?
Posté par samerw . Évalué à 5. Dernière modification le 06 septembre 2018 à 14:10.
Si vous utilisez notre module, vous pouvez empêcher l'utilisateur d'utiliser les options de tcpdump qui lui permet de devenir root. En effet, il suffit de définir un role en lui donnant le privilège cap_net_raw et le limitant à l'argument -i par exemple.
N'hésitez pas à le tester.
[^] # Re: faille tcpdump?
Posté par HL . Évalué à 1.
Mettre en
chmod +sune commande qui peut exécuter un script passé en paramètre, c'est plus du PEBKAC non ?# Appel aux testeurs et aux contributeurs
Posté par samerw . Évalué à 7.
Comme vous pouvez le constater, dans la page Github nous avons une section "to do list", n'hésitez pas à lire cette section et à nous proposer des idées ou bien contribuer directement au projet.
N'hésitez pas aussi à nous envoyer vos résultats des tests.
Merci d'avance
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . Évalué à 1.
Je mettrais en tout premier de la liste : soit virer le xml, soit développer un outil permettant de ne pas avoir à manipuler cette horreur.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par samerw . Évalué à 2.
Virer xml non mais developper des outils pour l'éditer oui (c'est déjà prévu).
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Pourriez faire du YAML. Quasiment la même chose mais en plus léger !
C'est ce qui se passe avec cette usine à gaz de polkit (un remplaçant lui aussi de sudo chiant à configurer). Les fichiers systèmes sont en XML mais on peut les surcharger en YAML parce que le XML, c'est vraiment très chiant pour l'admin système.
À noter que polkit n'a pas réduit l'usage de sudo… Parfois, c'est tellement peu claire que je préférais avoir une ligne claire dans sudoers que ce genre de droit compliqué à tester et qu'on ne sais pas trop si cela marche ou pas alors on élargit d'office !
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par samerw . Évalué à 4. Dernière modification le 06 septembre 2018 à 17:26.
Je vous remercie pour cette proposition.
Je vais l'étudier et voir si on peut faire du YAML à la place de XML.
Notre objectif est d'étudier l'utilisabilité de notre solution par rapport aux solutions existantes. Je pense qu'il nous manque un peu du support de la part du kernel pour améliorer l'utilisabilité de notre solution. En effet, aujourd'hui le kernel utilise cap_capable() dans le kernel pour vérifier si un processus possède un privilège ou pas. Le problème c'est que cette fonction retourne toujours le meme code erreur quel que soit le privilège vérifié. Si cette fonction est modifiée pour retourner avec le code d'erreur le privilège vérifié, nous pourrons exploiter cette information pour indiquer à l'utilisateur le role qu'il doit assumer.
bref, une modification du kernel est nécessaire pour améliorer notre solution. Nous allons travailler sur cet aspect prochainement.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 5.
« le XML, c'est vraiment très chiant pour l'admin système »
T’es sérieux quand tu dis ça ?
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Dring . Évalué à 9.
D'accord pour dire que "très chiant" c'est exagéré.
Cela dit, XML reste pénible à utiliser/taper/lire, et perso, partout où j'ai le choix pour de la configuration, c'est JSON ou YAML/INI, en fonction de "contexte web ou pas web, complexe/simple".
YAML a l'avantage d'être également utilisé par d'autres outils type Ansible qui ont potentiellement la même base utilisateur. XML reste rare pour tout ce qui est setup du système de base.
Je garde XML pour de l'échange de données inter-systèmes et quand une validation formelle en entrée ou en sortie est nécessaire.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Albert_ . Évalué à 3.
Sais tu que YAML (enfin json) a un system de validation? Cela s'appelle json schema et c'est directement utilisable avec yaml.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Dring . Évalué à 2.
Je l'ignorais, mais je ne sais pas encore si ça change grand chose. Entre "ça existe" et "c'est utilisé et suffisamment répandu pour que je puisse m'en servir", il y a un pas.
Je vais creuser, merci pour la piste. Ca pourrait permettre de sortir des erreurs plus propres.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Oui, c'est pénible à éditer, à écrire, à faire des "grep"…
Je trouve que la solution choisie par polkit, les fichiers de la distributions polkit en XML et la surcharge de l'admin systeme dans /etc en YAML très bien.
Le XML, c'est bien pour les interfaces graphiques, pas trop pour la CLI. Ne rendons pas trop le système trop dépendant des interfaces graphiques comme l'OS de Microsoft !
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
J’essaie de comprendre. Tu édites le XML avec ed ? Quand tu fais un grep, ça te renvoie tout le fichier sur une ligne ? Pourquoi tu parles d’interface graphique ?
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'édite avec vim en général… Quand je fais un grep sur un fichier YAML, cela renvoi juste la(les) bonne ligne dont il facile d'extraire la valeur avec cut ou awk. Bref, c'est plus facile de faire de la GLU en ligne de commande avec le YAML qu'avec le XML. Sinon, on voit souvent le XML dans les applications graphiques car -1- avec les schémas, c'est facile à valider coté dév et -2- malgré le coté verbeux, ça marche bien. Java et Tomcat en ont d'ailleurs un peu abusé ;-)
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 7.
Vraiment ? Faut arrêter que l'ont utilise grep/less pour vite fais se retrouver dans un document pourquoi pas, mais c'est des langages qui ne sont pas parsables avec grep, sed ou awk. Que ce soit ini, json, xml ou yaml. Le fait que tu en ai l'impression ne fait que te faire écrire des bugs que tu n'a pas encore découvert. Si json était parsable avec ses outils
jqn'aurais pas de raison d'être. Seul awk est capable d'avoir un contexte, mais si tu veux te servir d'awk pour ça tu va rencontrer pas mal de difficulté.La phrase de Douglas Mcliroy c'est « Make each program do one thing well » (qu'on traduit généralement par « Écrivez des programmes qui effectuent une seule chose et qui le font bien ») et pas « binutils can make all things ». Quand tu parse un format qui n'est pas conext-free, utiliser des outils qui sont context-free c'est aller au devant de jolis problèmes. Je suis persuadé que pour le moment vu que c'est toi qui écris les parseurs et que les formats d'entrée n'ont pas trop évolués « ça passe ». Mais « ça passe » ça veut juste dire que le cas nominal fonctionne. Je présume que je peux casser ton parseur juste en construisant le fichier qui va bien sans changer son format et je sui parfaitement certain de pouvoir casser silencieusement ton parseur si je modifie le format.
Donc personnellement, je dirais que si xml permet de démotiver les gens à tenter de faire du parsing en grep/sed, il vaut mieux faire du xml.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4.
"c'est des langages qui ne sont pas parsables avec grep, sed ou awk"
On doit pouvoir les parser avec xml-grep, xml-sed ou xml-awk ?
…
ben si ça existe
"personnellement, je dirais que si xml permet de démotiver les gens
à tenter de faire du parsing en grep/sed, il vaut mieux faire du xml."
Je comprends ce point de vue mais ça ne me semble pas très constructif.
Je me suis rendu compte au boulot que très peu de gens connaissent les bases
en XML, y compris dans les domaines ou c'est incontournable, et donc on a souvent
droit à une réaction de rejet et des décisions idiotes (remplacement par "du CSV pour
des dinos ou du JSON pour des hipsters").
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 5.
Ça n'a rien avoir. On peut très bien écrire des parseurs oui. Mais xml-grep, n'est pas grep.
Si le besoin de tes utilisateurs, c'est de faire du grep alors, tu utilise un format qui se manipule bien avec grep. Laisser des légendes urbaines comme csv ou yaml ça marche avec mon sed, ça va poser des problèmes soit à toi soit à très utilisateurs. Le seul format véritablement parsable avec ces outils c'est properties. Le truc c'est qu'en vrai ils s'en foutent ce qu'ils veulent c'est que ce soit joli ou conci. Parce que c'est forcément plus lisible (les liens de documents en yaml ? Les chaînes de caractères qu'on peut écrire de 3 ou 4 façons ? L'indentation relou avec les chaînes de caractères multilingnes?…). Tu ne trouvera personne pour dire que ngnix a un format de configuration pas bien parce qu'il ne peut pas être parsé via grep et pour le coup tu ne trouvera rien qui te permet de le parser. Non c'est xml qui a mauvaise presse pour des raisons qui n'ont rien de rationnelles. Tu peux trouver des gens qui sont fort de manipuler du html à tour de bras,mais qui vomissent xml.
Xml est un format qui a pleins de problèmes et qui est souvent mal implémenté, mais ceux qui sortent des arguments comme réécrit ton outil avec yaml parce que moi j'aime bien yaml, me donnent plus envie de tout remplacer par asn1 que par le truc à la mode qu'ils auront trouvé.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Sytoka Modon (site web personnel) . Évalué à 4. Dernière modification le 11 septembre 2018 à 11:05.
Ton programme (ou mon programme) se configure avec du YAML et le lit avec un vrai parser YAML (donc conforme). Donc tout va très bien. En quoi est-ce un problème de pouvoir faire un grep, un ack ou un awk dessus pour certaines taches de recherche / contrôle ? Par exemple un test Nagios ou autre…
Bref, un "egrep 'ChapeauCrochetCrochet:space:CrochetCrochet*clef:' | awk '{print $2}'" renvoie la valeur d'une clef et cela peut être très pratique dans certains cas. C'est lisible et pour moi, c'est pas un bogue d'écrire cela ! J'ai jamais dis qu'il fallait parser 100% du fichier YAML en Bash !
Après, il y a effectivement des personnes pour qui il faut un programme Java ou un pip install d'une détrachiée de module pour juste lire une clef d'un fichier.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 4.
Parce que c'est du bricolage qui ne marche pas. Le fait que ça marche pour l'exemple sur le quel tu l'a fait à l'instant où tu l'a mis en place ne dis pas que ça fonctionne. C'est vraiment très fragile comme fonctionnement et baser ton monitoring sur quelque chose d'aussi fragile c'est vraiment pas une bonne idée. Tu veux pas que ton monitoring casse plus souvent que ton environnement en principe. Passer son ton à faire de la maintenance de scripts c'est une perte de temps. Surtout qu'il est vraiment facile d'utiliser un outil adapté.
Mais surtout je dis que c'est pas un argument pertinent plus qu'un problème. Que tu fasse n'importe quoi dans ton coin, tant pis pour toi, que tu demande de changer le logiciel pour pouvoir faire n'importe quoi c'est une demande qui n'est pas particulièrement argumentée.
Et ta super ligne donne quoi sur :
Comment font les gens pour utiliser nginx si c'est nécessaire d'avoir un parsing grep/sed/awk ?
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Mon dernier post car tu est de mauvaise fois. Je te dis que c'est intéressant pour tester une clef particulière dans certain cas et tu me sors un fichier YAML complexe avec deux fois 'clef' et des machins multi-lignes. J'ai bien dis que je ne parse pas du YAML depuis Bash ! Uniquement quelques cas simples… En règle générale, j'utilise un vrai parseur avec un langage qui gère cela très bien comme Python ou Perl par exemple.
Tu dis que c'est fragile… Il y a tout plein de cas ou la clef est unique et le fichier YAML très très simple. Tu fait un test super simple et la maintenance ne change pas tant que le service tourne. Le jour d'une grosse mise à jour du service, tu mets à jour le test mais cela, c'est le cas quelque soit le test !
Si ton système de configuration des serveurs est versionné (git…) et avec déploiement automatique sur les postes (puppet…), la mise à jour une fois tous les 3 ans d'un test de deux lignes qui génère un faux positif n'est pas forcément une perte de temps. Je ne fais pas partie des fanatiques qui veulent sortir Bash des systèmes UNIX ;-)
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 1. Dernière modification le 11 septembre 2018 à 15:25.
Le coût d'utiliser un outil adapté (yq, (jq)[https://stedolan.github.io/jq/] ou xml-coreutils) est beaucoup trop faible pour qu'utiliser autre chose soit acceptable. Faire les choses bien n'est pas plus compliqué ça demande seulement de vouloir le faire.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par fearan . Évalué à 4.
yep ça c'est typique le gars qui lorsqu'il doit faire un script qui tourne une fois sur un cas simple et dont les valeurs sont prévisibles, va installer 50 bibliothèque / exécutable pour faire en 2J ce qu'une ligne de commande écrite en 2 minutes fait.
Mais au moins c'est propre !
Et encore j'ai pris le cas où le service info fait son taf, et qu'en plus l'utilitaire est dans les repos.
Et puis c'est aussi à supposer que l'outil n'a pas de bug. J'ai parlé du module xpath de python qu'est pas capable de gérer les namespace XML ?
Et parfois le coût il est pas 'trop faible'; lorsque tu te contente d'un grep ça va; quand tu dois faire un enchainement de grep -B, puis grep -A…
Note bien j'ai rien contre faire les choses propres, pour la configuration des bases décrites dans un xml, je les chopes via du xpath.
Mais parfois c'est plus simple/rapide/efficace de se passer des outils dédier.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 3.
Tu veux faire modifier l'outil pour une action que tu fais une fois à l'arrache ? Faut se plier aux demandes pour chaque lubies du cas particulier du gars qui utilise un truc une fois et qui veut pas s'embêter et donc préfère faire porter le travaille sur les dev ?
2 commentaires plus haut il est question de faire faire ça à l'outil de monitoring, hein ?
Il était question de faire faire ça à nagios, hein ?
J'ai vu bien plus de bug dans scripts de scripts kiddies que dans les bibliothèques. Sûrement parce que l'un des 2 écrit des tests et pas l'autre ?
C'est comme si tu disais qu'utiliser la commande
docker, il y a pleins de fois où c'est compliqué alors que tu peut tout faire avec ton netcat/socat tu peux directement tout faire sur la socket unix du deamon. Avoir l'outillage qui permet de manipuler les logiciels que tu gère c'est ton job, le mode « j'y vais avec ma bite et mon couteau » c'est pas un gage de qualité. Sélectionner et savoir utiliser ses outils et en comprendre les limites, c'est le boulot d'un opérationnel.[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Non, c'est une tétrachiée ! Et ça vaut 44.
Un chiée, ça fait onze et onze fait chiée. Par conséquent une tétrachie vaut 4 fois plus donc 44.
Par extension, l'expression courante "une tétrachiée plus une vaut 45.
Qu'on se le dise !
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . Évalué à 4. Dernière modification le 08 septembre 2018 à 18:37.
Ben moi je le pense sérieusement.
J'utilise les 3 formats (json, yaml et xml) quasiment tous les jours, et c'est xml qui pose le plus de problème.
Le XML n'a jamais été fait pour être éditable par un humain.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Alex G. . Évalué à 6.
Là on bascule dans l’extrémisme :-D
XML dérive se SGML qui a quand même été pensé pour l'utilisation par les humains (c'est quand même pas du binaire ou du BSON ou du gzip !).
Mais ce qui est sur, YAML est né comme une alternative plus facile à manipuler par les humains.
Perso je trouve qu'effectivement YAML a un bon équilibre flexibilité / facilité d'édition, et reste très facile à utiliser coté programme. Donc je trouve que c'est pas mal pour la configuration.
Il reste une fonctionnalité de XML qui manque, à mon goût, à YAML, c'est les namespaces.
(PS: je suis contre JSON pour la configuration pour la simple raison que en JSON, pas de commentaires, ce qui est une plaie dans ce cas).
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Le YAML est très bien et je l'utilise et le promeut depuis des années mais il a aussi des inconvénients. Il est vrai que les outils de validation sont moins nombreux et que si on fait un fichier hyper long très complexe, il peut lui aussi devenir compliqué à gérer.
Bref, YAML est super pour les choses simples ce qui me semble le cas présent sur l'outil "CAP" proposé.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . Évalué à 5.
D'après wikipédia, L'objectif initial de XML est de faciliter l'échange automatisé de contenus complexes (arbres, texte riche…) entre systèmes d'informations hétérogènes (interopérabilité) .
J'essaierai de retrouver d'autres sources (celles que j'avais utilisées à l'époque ou je me suis intéressé à xml - ce doit être un bouquin de chez o'reilly) qui détaillent un peu plus tout ça. mais si ma mémoire ne me fait pas défaut, et ma compréhension de l'époque était la bonne (et je peux avoir mal compris), le fait qu'xml soit manipulable par des humains n'est qu'une conséquence, pas le but.
Sinon, le xml ne me dérange pas lorsqu'il est utilisé à bon escient (je pense par exemple au format OpenDocument, ou au format svg), mais lorsqu'il s'agit de choses éditables par des humains, tel que des fichiers de conf, j'ai tendance à ne pas aimer (je n'aime d'ailleurs pas le format de fichier de conf d'Apache qui est une espèce de pseudo xml/html qui est parfois lourd à manier et difficile à comprendre).
Là je suis tout à fait d'accord avec toi : je ne trouve pas le yaml parfait, mais beaucoup plus facile à utiliser pour de la conf (ou des trucs qui doivent être édités/manipulés par des humains).
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . Évalué à 7.
Même pour ça, c'est mauvais, qui n'a pas eu à faire des transformations XSL enchaînées avec les "&" qui se transforment ou pas en "&" aux mauvais endroits me lance la première pierre.
j'ai beaucoup utilisé XML dans sa période "hype" au boulot entre 2000 et 2005, et en vrac les inconvénients majeurs :
1) un fichier xml ne peut pas se traiter en flux à cause de la balise "racine" (il faut construire l'arbre en mémoire, ou comptabiliser les noeuds avec SAX), alors que le CSV (certes format pourri antédiluvien) ou tout autre format "plat", je peux lire 1000 lignes un jour et reprendre à la 1001 le lendemain et la mémoire occupée est seulement la ligne courante.
Maintenant parlons de millions de lignes de données à passer dans un batch…
Ce n'est pas un bon format d'échange de données en masse.
Ces fichiers ne sont pas vraiment "parcourable" avec les outils standards linux (cf remarques dans les posts au dessus), et pour ceux qui feront la remarque "il y a des outils adaptés", oui, chez moi sur mon ordi, j'installe ce que je veux, en entreprise/client, on fait avec ce qu'il y a d'installé quand on n'est pas l'administrateur, et selon les versions OS et les outils installés, et bien vous risquez de n'avoir que du "notepad de base" niveau fonctionalités.
1bis) Quand vous devez mettre en relation plusieurs balises pour interpréter le fichier XML (rassembler des champs différents pour fabriquer une requête SQL par exemple), et bien là, il faut passer par DOM, et le fichier sera intégralement chargé en mémoire avec la création de tous les noeuds du DOM, et c'est très loin d'être gratuit.
Si en plus les fonctionnels ont pris un malin plaisir à éclater les données a l'opposé dans le fichier et que vous avez des données en masse, j'ai du monter une JVM à 16Go pour pouvoir échanger des fichiers de millions d'enregistrement.
2) il y a beaucoup trop de symboles spéciaux ("<,<!,>,&,…" contrairement au "\" des fichiers textes), du coup, comme je le disais plus haut, des transformations XSL sur XML en chaîne ne sont pas stables, et c'est parfait pour arracher les derniers cheveux qui vous restent sur la tête, parce qu'un caractère spécial sera transformé en entité et la série de transformation deviendra un fichier inutile (déjà vu des <root> [= ] )
et les <![CDATA[]]> qui rajoutent un bon paquet de merde.
C'est un format fragile rien que pour ça.
3) validation du schéma, maintenant on a json et yaml qui ont l'équivalent et ce sont des formats plus léger en taille et à la lecture, donc ce n'est plus un argument.
4) et puis surtout, il faut des outils prévus pour, là on a notepad++ chez le client, j'ai pu ajouter le plugin XML, mais sans plugin, c'est indigeste à la lecture et on peut facilement oublier une balise sans un analyseur de syntaxe.
Pour résumer, lourd, fragile, instable et il faut des outils spéciaux qui ne sont pas forcément installés chez le client.
J'en ai bouffé du XML, j'étais un "expert", et bien je ne veux même plus entendre parler de XML sur des nouveaux développement.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
Que dis je un "expert", un [:méta expert] !
-> Tu ne sais pas travailler avec du XML, va faire du JSON et du YAML (et du CSV).
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . Évalué à 0.
Je me fous complètement du format des fichiers.
ça fait longtemps que je ne luttes plus sur ces questions quand j'arrive sur un projet déjà commencé ou les choix ont déjà été fait.
L'année dernière, j'ai travaillé sur un composant qui s'appuyait sur une API qui était binorme, SOAP et REST selons les appels.
ça fait longtemps maintenant, mais j'ai aussi travaillé sur une API XML pré-SOAP
Je n'ai rien contre le XML en soi, je dis que ça rajoute de la lourdeur au traitement/
Que ça soit pour les machines, le parsing n'est pas gratuit, le DOM en mémoire n'est pas gratuit, ou pour les humains, c'est plus "indigeste" de travailler avec.
Et qu'il y a une divergence entre ce que le XML devait apporter et l'utilisation concrète sur le terrain, ça devait nous faciliter la vie, je ne touve pas vraiment.
Je suis plus Java, c'est quand même bizarre que Spring ait eu autant de succès, alors qu'il ne fait pas plus que les anciens framework web+JEE+EJB avec leurs milliards de fichiers de conf XML.
Si les technos sont des plats, je n'aime pas le plat XML, et pourtant j'en mange quand il n'y a que ça, ce n'est pas pour autant que je dois dire que c'est "délicieux".
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 1.
Spring a eu du succès à l'époque de sa configuration XML (d'ailleurs il y a toujours des choses qui ne se font qu'en XML, même si on peut s'en passer) et JavaEE require plus de XML.
Spring a eu du succès parce qu'il était simple (un bean spring et un EJB sont très différents) et parce qu'il a su s'intégrer avec pleins de choses. Si on ajoute à ça qu'il repose sur un conteneur de servlet plutôt que sur un serveur d'application complet (et souvent payant).
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . Évalué à 4. Dernière modification le 28 septembre 2018 à 10:37.
On peut quand même noter que la mode "XML à toutes les sauces" (sur le tapis … :) ) est bel et bien tombée, et qu'on est maintenant dans une utilisation un peu plus "raisonnable" de ce format.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 0.
Tout à fait, mais pour le cas présent c'est les annotations qui ont remplacés XML. Et vas y pour parser ça avec grep.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . Évalué à 1.
Spring a réussi, parce que c'était moins "lourd" à l'usage.
Entre une annotation devant la méthode qui l'utilise dans son fichier source dans son coin et un fichier externe (qui pouvait être commun entre plusieurs classes, pb de verrous quand il y a plusieurs dev par exemple…) ou je dois faire le mapping dans ma tête entre ce fichier de conf XML et le code source, et bien bizarrement, je préfère faire des annotations.
"grep -R @annotation *", c'est très très difficile comme syntaxe :-)
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 1.
Spring a commencé à acier du succès bien avant l'arrivée des annotations et je te pris de continuer à faire tes grep quand tu as par exemple des annotations de mapping pour les routes qui sont hiérarchiques ou quand tu fais usage des profils ou… Dans tout ces cas faire un grep sur des annotations est aussi pertinent que sur du XML.
Ce qui fait la légèreté de Spring ce n'est pas le format de sa configuration, mais le fait qu'il utilise des concepts bien plus simple (voir ce qu'est un EJB face à ce qu'est un bean spring).
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 3.
Tu es entrain d'expliquer qu'on peut mal utiliser une techno. Et oui on peut avoir des formats débiles. Au boulot (véridique) on accède à un webservice qui te donne un zip qui contient une base de données sqlite. Je ne vais pas expliquer que sqlite c'est pourri et que je ne veux plus en entendre parler.
Pour ce qui est des outils, je ne sais pas chez quel client tu travail (et c'est pas vraiment mon problème), mais je ne comprends pas comment on peut accepter de travailler sans outil. Et ça fait parti de ton job de t'outiller correctement. Se défausser sur le client c'est pas très classe. Surtout qu'il faut de l'outillage spécifique pour json ou yaml.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . Évalué à 0.
Sur les postes de travail, en général, tu peux installer un peu ce que tu veux (et pas toujours, je suis déjà tombé chez des clients qui ont une image standard du poste de W et tu n'es pas admin sur le poste de W pour installer de nouveaux outils, il faut trouver des versions "sans install").
Mais sur les serveurs, soit par "principe" de ne pas augmenter le nombre de technos/d'outils installés (moins d'éléments, moins de problèmes) ou parce que l'équipe administration ne veut pas s'écarter de la configuration standard de leur OS.
Surtout si les outils en questions ne font pas parti directement des dépôts éditeurs (dépôts tiers ou pire compilation des sources) et ne sont pas impliqués directement dans la "production" du SI (que l'outil de visualisation/édition soit là ou pas, ça ne changera rien au résultat produits par le SI).
Du coup, en général, si on peut faire du sftp/ftp sur les serveurs, ça crée une étape intermédiaire ou on rappatrie les fichiers sur le poste de W, c'est juste plus lourd.
Et oui, après plusieurs mois de bataille "politique" pour montrer le bien fondé de l'installation (inertie, résistance au changement, NIH,…), tu peux peut etre avoir les outils, mais le projet est déjà terminé.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 1.
Alors l'outillage côté serveur n'est pas forcément très utile et côté client, je ne bypass pas les politiques des boîtes où je travaille. C'est juste comme si on me demander de coder avec notepad (c'est bien ça l'éditeur de texte tout pourri de Windows au moins jusqu'à XP ?).
On peut faire sans. Il y a des générations de gens qui ont codé dans gestionnaire de source, sans revue de code, sans intégration continue, etc C'est pas pour ça que je vais accepter de bosser sans (ou plus précisément dans un plan qui mènera à les installer et les utiliser dans un temps limité).
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . Évalué à 2.
Euh .. tu as déjà eu à gérer des serveurs de prod ?
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 1.
Plus que tu ne le crois. Je n'edite juste pas de XML sur serveur. Actuellement je suis même entrain de voir pour virer le shell, vi, etc. La prod deviendra alors un cluster k8s. Autant ça peut m'arriver d'utiliser des outils comme tcpdump pour voir ce qui se passe sur le réseau autant je ne vois pas ce qui me ferais éditer un fichier. Sachant que j'ai bossé sur des prod variées et publiques (voir assez chargées).
Maintenant qu'on en a fini avec les personnes tu va m'expliquer que "dans la vraie vie" on édite les fichiers de prod à la main parce que le client c'est qu'un méchant etc ? Il n'y a personne qui a entendu parler d'infrastructures immuables ? Ou d'infra as code ? Il existe des trucs au dessus de docker ou autres techno de container.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . Évalué à 0.
Par contre le serveur qui contrôle le cluster, m'étonnerait que tu vires le shell et VI dessus.
Les conteneurs c'est un peu un cas à part, c'est plus une "grosse commande/applicatione" qu'on ajoute au serveur hébergeur qu'un "serveur", donc oui, on peut les dépouiller de tout, limite réduit à init+process appli (on peut même aller plus loin et se dire qu'on peut virer le scheduler du kernel, vu qu'il y a une seule application qui tourne et est nécessaire).
Tous les directions informatiques ne sont pas au même niveau de compétence ou même niveau de technologie.
Des concepts qui marche pour l'un, ne marcheront pas pour les autres.
Et qui n'a jamais modifié un fichier de conf de prod en "live" pour débloquer le SI suite à un incident qui bloque tout et qui met en péril l'activité commerciale immédiate (bizarrement de votre chef direct jusqu'au DSI et le DG débarquent dans votre bureau) me jette la première pierre.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 2.
Tu nous sors l'argument de la bombe qui va exploser et du terroriste ? Moi aussi j'ai fais ce genre de trucs, mais il faut comprendre que c'est super dangereux et que tu perds toutes un tas de propriétés utiles quand tu commence à faire ça. Que des gens le font, j'en ai aucun doute, mais est-ce que c'est pour ça qu'il faut se forcer à autoriser ce type de workflow ? Évidemment que non. Si tu en arrive là, le problème ce n'est pas le format et les outils qui lui sont associé mais que tu manque de souplesse dans les interventions en prod. Il y a tout un tas de choses qui servent à palier à ça, il est tant de s'en servir.
Si tu fais ça tu ne peux plus faire confiance à ton gestionnaire de configuration, par exemple.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4.
Ce que l'on lit dans tes commentaires, c'est surtout une certaine souffrance au travail. Personne ici ne va te jeter des cailloux, tout individu qui a fait de la production a eu droit a ses quinze minutes de gloire avec le DSI ou le DG en mode panique et a pu faire des trucs inavouables pour redémarrer le bouzin.
Quand le DSI ou le DG s'assoient sur tes genoux, c'est justement le moment de leur faire signer les papiers qui t'autorisent à aller en formation, à acheter les licences des outils dont tu as besoin, à les installer ou il faut, bref à faire ton boulot dans de bonnes conditions.
"Ou il a appris à négocier ?"
A chaque fois qu'un sysadmin joue au superhéros et sauve la boite sans obtenir de contreparties (je parle pas d'une tape dans le dos ou d'une prime), il maintient son SI en risque opérationnel et quelques incapables décisionnaires dans leur déni de la réalité. On a peu de cartouches, il s'agit de ne pas les gaspiller.
De plus, le jour ou le super héros veut partir de la boite, il faut trouver un autre super héros pour mettre à la place, et ça coûte de plus en plus cher.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . Évalué à 3.
Ben moi ça m'est déjà arrivé de devoir au moins visualiser un fichier xml sur un serveur de prod, pour vérifier que celui-ci était bien conforme à ce qui était attendu.
Ben si, je bosse en plein dedans en ce moment. Il m'arrive d'aller voir sur des serveurs de prod si des fichiers de conf sont bien conforme à ce que je m'attends d'avoir, même dans le cadre d'infrastructure as code (parce que il nous est déjà arrivé dans des phases de déploiement d'avoir des choses bizarres qui se passent parce qu'une combinaison de causes non imaginées donc non testées ont pour conséquence de corrompre des confs). Et dans ce cas il peut être nécessaire de corriger manuellement le problème en attendant que les référentiels ou les outils de déploiement soient mis à jour.
Donc même avec des trucs du style infra as code, il sera toujours nécessaire d'avoir moyen de savoir ce qui se passe sur un serveur (là ou je suis en ce moment, ya des personnes qui veulent aller jusqu'à interdire les connections ssh, mais je suis certain que ça n'arrivera jamais, ou si ça se fait, on reviendra rapidement en arrière).
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 1.
Ça t'arrive tellement souvent que le rapatrier, ça prend trop de temps ? Parce que lire le fichier c'est bien, en faite un diff graphique c'est potentiellement plus pratique, le comparer avec n'importe quel autre version de ton gestionnaire de conf c'est encore mieux… Tu va installer tout ça sur ta prod ? Parce qu'il est déjà arrivé d'avoir un défaut et que tu as eu la flemme de le rapatrier ? Si la DSI reçoit des demandes farfelues c'est logiques qu'ils deviennent moins flexibles.
Mais c'est bizarre d'avoir les livrables qu'en prod.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . Évalué à 0.
Evidemment que c'est super dangereux et que ce n'est pas un fonctionnement normal, mais ça arrive, et là tu es bien content de pouvoir agir en direct sur le serveur, surtout si le réseau est aussi en vrac au passage pour transférer ladite conf (et quand tu as toute la hiérarchie sur le dos, tu as l'impression de rejouer une mauvaise scène "couper le fil bleu ou rouge").
Ben quand l'équipe admin met en place plusieurs rebonds pour accéder à un serveur, çà peut vite devenir ca°°e-co°°°les.
Après dans l'idée générale de rendre le SI moins friable, plus carré, plus référencé, plus automatisés, avec des composants minimum (surface d'attaque réduite) je suis à 120% d'accord, mais encore faut il être le "maître des clefs".
Quand on débarque sur un SI "étranger" où on n'a jamais participé à sa création/évolution, et bien on s'adaptes à leurs habitudes.
Ou alors tu fais le TJW (Technical Justice Warrior :-) ) et tu te mets les internes à dos.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 1.
Non, je suis content quand je ne peux pas le faire. Si je peux le faire, on va me forcer à le faire et je vais déclencher un post mortem pour expliquer aux gens pourquoi c'est pourri, que si leur prof est si importante que ça il va falloir changer certaines choses et on tente de mettre un plan à exécution pour que ça ne se reproduise jamais. Si le mec que tu fais travailler sous pression comme ça fait une erreur tu peux le payer très chère.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . Évalué à 2.
Donc toi tu préfères bloquer la prod potentiellement pendant plusieurs heures ? De toute façon, même dans un SI géré le mieux du monde, tu n'es pas à l'abri de ce genre de problème. Tellement pas à l'abri que c'est prévu par des pratiques comme ITIL: un workaround doit être tracé et faire l'objet d'une action correctrice.
Après je ne prone pas les modifs sauvages en prod, mais je ne prone pas non plus l'autre extrême dans laquelle tu sembles tomber.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 2.
Produire une nouvelle version du fichier incriminer et l'appliquer ? On parle en minutes. Remettons dans le contexte, vous parlez de modifier un fichier directement en prod, je parle de le réuploader. Si appliquer une modification te prends autant de temps c'est surprenant.
Tout à fait et tracer un coup de vim à l'arrache c'est l'assurance qu'un jour quelqu'un va oublier ou à minima mal retranscrire son coup de vim (ou ne pas s'être rendu compte que son
sed -in'a pas fais que ce qu'il pensait).Je dis que je n'ai pas besoin d'outil en prod parce que je passe par des uploads/downloads et j'explique que si tu fais les choses à la main, tu ne peux plus te servir de gestionnaire de version, que m'expliquer que tes artefacts n'existent que sur les machines de prod c'est très louche, bref que vous ne sortez des arguments qui sont juste là pour maintenir des workflows qui posent un tas de problème alors que pour moi le problème n'est pas le format XML, YAML ou ASN, mais le workflow dangereux.
Si tu n'a pas le temps de télécharger le fichier en question c'est que tu as vendus des niveaux de services où ce genre de problème ne peuvent pas arriver.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . Évalué à 2. Dernière modification le 28 septembre 2018 à 18:00.
Ben il n'y a pas que le temps qui rentre en compte. Parfois il y a aussi l'environnement qui est hostile (réseaux séparés nécessitant de passer par des machines de rebond plus ou moins sécurisées par exemple, qui rendent les transferts de fichier difficiles).
Pas toujours possible. On parle d'infra as code, avec des confs calculés, et qui peuvent se vautrer lorsqu'on se trouve dans un cas pas prévu ou mal spécifié dans la demande initiale. Exemple: combinaisons d'installation via déroulement de playbooks/roles ansible qui n'ont pas été prévus pour fonctionner ensemble, et peuvent se marcher l'un sur l'autre et produire des confs étranges dans un cas qui n'a pas été identifié. Difficile (mais pas impossible) de voir ce qui se passe dans le gestionnaire de conf. Si tu peux te baser sur la conf générée par ton outil, ça peut donner des pistes de recherche.
Tout dépend de la criticité de la prod et des contraintes autour. parfois on va décider de revenir en arrière, corriger le problème, tester et redéployer ultérieurement. Parfois on va modifier direct la prod et ouvrir un ticket d'incident pour corriger le problème. Tout dépend de ce que ça coûte dans chacun des cas. Juste modifier un playbook ou un role + redéployer n'est pas toujours envisageable car les playbooks/roles peuvent être utilisés par ailleurs, et modifier pour le cas spécifique du bug peut en entrainer d'autres pour d'autres déploiements.
La meilleure méthode reste toujours de corriger à la source, mais parfois c'est long à implémenter/tester donc en attendant la correction à la source et l'automatisation, on utilise un workaround directement en prod.
De mémoire non. De toute façon, que l'on corrige ou pas en direct sur la prod, il faut que le problème soit corrigé et que nos tests soient mis à jour pour éviter les régressions.
Parce que si je modifie la prod, je m'assure que ce soit tracé pour que le correctif soit apporté (et pour tout dire, en ce moment c pas moi qui modifie la prod, je suis plutôt chargé de créer les playbooks de déploiement et de les corriger en cas de problème). Et quand j'ai un bug à corriger, je dois passer par un cycle de développement/test/livraison qui peut parfois prendre plus de temps qu'une correction en live.
Pas si bizarre que ça. Parce que
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par barmic . Évalué à 1.
Effectivement ça peut arriver. J'ai un ami qui bosse pour les centrales nucléaires et effectivement rien est accessible à distance. Ça reste des conditions particulières. Dire que XML c'est pourri parce que tu ne peux pas installer ta coloration syntaxique sur ton projet c'est un peu fort. C'est éventuellement pas le format qui arrange ton projet, mais je ne ferais pas de généralité de ces cas alors qu'au contraire une grande partie des projets finissent dans du cloud par exemple.
Je ne compile pas mon projet en pro que ce soit le code source ou l'infra. en prod j'upload le résultat de ma compile, ce qui fait que tous les fichiers en prod sont aussi chez moi et c'est bien pratique pour reproduire la prod.
Tu soulève un point intéressant, je n'avais pas vu ce problème dans les gestionnaires de conf, mais c'est à prendre en compte. Je ferrais attention à limiter fortement la complexité de ces trucs là.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . Évalué à 0.
Quand je disais "notepad de base", c'est une galéjade, c'était pour dire qu'il n'y avais pas le dernier IDE/Text Editor/commande en ligne ou graphique avec tous les plugins "qui vont bien" à la mode ou qu'on maitrise du bout les yeux fermés et qu'il n'y aura pas les facilités qu'on a l'habitude d'utiliser à la maison ou quand on est dans une petite équipe indépendante.
Evidemment, que si on est réellement forcé de travailler avec un text editeur de base comme seul outil et aucune commande en ligne avancée, ça serait l'équivalent de creuser une tranchée à la cuillère, et pas grand monde l'accepterait, moi le premier.
# Problèmes
Posté par barmic . Évalué à 3.
Donc si je résume bien vous listez 3 problèmes des
capabilities:Perso de ce que j'avais compris le principal problème des capabilities, c'est que ce sont de gros trous de sécurité :
False Boundaries and Arbitrary Code Execution.
[^] # Re: Problèmes
Posté par samerw . Évalué à 5.
Le système de capacité de Linux souffre de nombreux problèmes. En tous cas, si vous utilisez le mode no-root (-n option) vous répondez à certain problèmes cités dans le lien que vous avez fourni (False Boundaries and Arbitrary Code Execution). Le mode no-root permet de désactiver le traitement particulier de uid 0 et vous permet d'avoir un système qui considère root comme utilisateur standard.
# C'est quand même un changement profond de paradigme ...
Posté par totof2000 . Évalué à 3.
L'approche unix se base sur les droits attribués à un utilisateur sur les objets manipulés (fichiers, etc …) et non sur des droits attribués à un processus. Et je crains qu'ajouter une couche de contrôle au niveau processus ne vienne à rendre difficile la gestion des accès au ressources, surtout soi à ça on interagit avec d'autres couches telles que selinux par exemple. Après, si on intègre les diverses couches à un seul outil, pourquoi pas, mais vu qu'on se dirige de plus en plus vers des applications orientées microservices sur des containers/VM n'ayant que peu de choses qui tournent dessus, je me demande si les admins prendront le temps de gérer ce genre de choses.
[^] # Re: C'est quand même un changement profond de paradigme ...
Posté par samerw . Évalué à 4.
Il ne faut pas mélanger les permissions classiques des utilisateurs standard avec les privilèges administratifs de root. Les deux existent. Les processus possèdent des attributs pour pouvoir mettre en oeuvre les deux types de permissions.
# Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 6. Dernière modification le 06 septembre 2018 à 14:23.
Sur le système OpenBSD il y a le principe de
pledgequi est très intéressant à noter et qui, comme ici, permet de limiter le pouvoir qu'a un programme sur la machine. L'idée de pledge est d'ailleurs largement plus simple que les capacités du noyau Linux.On part du principe qu'un programme se compose généralement de 2 parties : la partie initialisation (on ouvre des sockets, des fichiers, on lit une configuration, etc.) et une boucle de travail (répondre à des requêtes HTTP par exemple). De ce fait, on sait ce qui doit et ne doit pas pouvoir se passer dans la boucle. On va donc dire qu'on assure n'utiliser par exemple que le réseau et le DNS avant d'entrer dans la boucle infinie, en indiquant dans le programme une simple ligne
pledge ("inet dns");et voilà.J'ai regardé légèrement SELinux, les capacités Linux, et encore deux ou trois autres systèmes comme ceux-là… on est à des années-lumière de la simplicité de
pledge, et du coup pas grand monde utilise ces mécanismes. Et au contraire, tous les programmes OpenBSD sont passés à pledge en l'espace de deux releases (une année), permettant de trouver des erreurs de programmation dans le code de certaines applications commeopenbgpd.(ma vie) C'est assez drôle d'ailleurs, la première fois que je me souviens avoir entendu parlé de SELinux était quand il fût responsable d'un problème de démarrage de programme sur ma machine.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 3.
Bonjour,
Je crois que vous mélangez les 'capability based access control model' avec linux capability. Vous avez raison de confondre les deux car Linux utilise le mot capability. Mais en fait ce sont deux choses différentes. Pledge, seccomp et encore capsicum permettent de contrôler les appels systèmes des processus. Linux capabilities (nous devons utiliser le mot privilege) c'est l'ensemble des permissions dans le kernel qui sont traditionnellement réservés au root.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 3.
L'objectif final est le même : rendre le système plus sûr en limitant le pouvoir de nuisance d'une faille. Et pour cela, dans tous les cas, on limite les droits d'une application. L'approche est certes différente, comme vous dites Linux capabilities est différent de seccomp, capsicum et pledge, mais on cherche à faire la même chose. Ce que je dis dans mon commentaire est justement ça : l'approche est différente, et en pratique moins intéressante à cause de sa complexité de mise en œuvre et du coup du peu d'intérêt pour les développeurs. Oui ça existe dans le noyau depuis longtemps, et le fait que pas grand monde l'utilise me semble révélateur de l'échec que représente cette approche.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 4.
J'insiste sur le fait qu'il ne faut pas mélanger le capability based access control modele avec Linux capability. Je m'explique: admettant qu'un programme souhaite ouvrir un raw socket. Le programme doit absolument posséder cap_net_raw privilège sinon le call socket ne va pas fonctionner. Nous appelons le retour du call socket (file descriptor) comme capability dans le domaine "capability based access control". Ce descripteur normalement doit être initialisé et passé à un autre processus qui n'a pas le droit de faire des appels aux syscalls…
Par ailleurs, notre module est plutôt un outil pour les administrateurs et les utilisateurs, mais pas pour les développeurs. Comme vous le savez, tous les programmes ne sont pas forcément bien développés (imagine un programme qui demande à utilisateur de faire un sudo car il a besoin uniquement d'un seul privilège). Le fait que les administrateurs et les utilisateurs possèdent des outils qui leur permettent de contrôler les privileges passés au programmes c'est forcément avantage.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 6. Dernière modification le 06 septembre 2018 à 16:05.
Je comprends bien ce que vous dites, et contrairement à un système comme
pledge, vous partez du principe qu'on ne touche pas à l'application mais on la contraint par une autre manière que la perte de privilèges volontaire indiquée dans le code. L'hypothèse de départ est différente, dans un cas on a le code de programmes dont on veut assurer encore plus la sécurité, de l'autre on part uniquement des binaires pour gérer la sécurité.Et c'est exactement ce que je disais : deux approches. Et là où on peut accepter qu'un programme "s'initialise" puis lâche ses privilèges avec pledge, le même fonctionnement est impossible avec les privilèges Linux et on doit séparer le programme en deux pour le même résultat : le binaire conserve ses privilèges même lorsqu'il entre dans sa boucle de fonctionnement donc l'initialisation doit se faire ailleurs.
Donc on a des hypothèses de départ différentes :
Un fonctionnement différent :
Des fonctionnalités et contraintes différentes :
Mais un même but final : contraindre une application aux seuls privilèges dont elle a besoin. On pourrait donc discuter des usages possibles de chacune des approches, certes, mais l'objectif est quand même identique.
Par ailleurs, dans les deux cas il faut bien qu'on sache ce que l'application est sensée faire pour y attribuer les bons droits… donc le fait d'avoir ou pas à modifier le code (quand on parle seulement d'ajouter une ligne de code), n'est pas un argument qui pèse lourd. Cet argument vaut surtout pour les applications non libres, où on n'a pas du tout accès au code source, sinon ajouter une ligne de code me semble préférable à la complexité des capacités Linux. L'approche (caricaturée) ici est donc "on ne gère pas la sécurité en amont, les admin feront le job plus tard".
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 3.
Merci pour ce commentaire assez intéressant.
Moi je pars du principe suivant: aujourd'hui nous utilisons tous les commandes sudo et su par défaut, ce qui est très dangereux. Tous les programmes peuvent avoir des vulnérabilités et certains programmes ne sont pas forcément bien écrits et ne gèrent pas les privilèges correctement dans leur code. Par ailleurs, quand on donne un ou deux privilèges à un programme, on n'est pas sûr que le programme va l'utiliser sur la ressource qu'il est censé utiliser. Par exemple, quand je donne le privilège cap_net_bind_service à un programme qui est censé l'utiliser pour écouter sur le port 80. Qu'es qui me garantit que le programme ne va pas utiliser ce privilège pour écouter le port 81?
Notre module est donc une amélioration de la situation actuelle. Mais un bon programme doit utiliser des approches comme pledge et capsicum. Il doit aussi savoir gérer les privilèges qui consiste à désactiver les privilèges quand il n'en a plus besoin. Vous pouvez regarder notre code source pour avoir un exemple mais aussi le code source de ping qui est aussi un bon exemple sur l'utilisation des privilèges.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Sytoka Modon (site web personnel) . Évalué à 1. Dernière modification le 06 septembre 2018 à 17:05.
Il me semble que l'approche pas capability marchait mal parce qu'il y avait au final quelques capability clefs qui font tout le job et que ce n'était pas bien réparti…
Je suis perso assez dubitatif. Par le passé, on a vu que cette approche par les CAP marchait pas trop, l’approche SELinux non plus (trop complexe)… Je crois qu'il faut essayé de plus faire confiance dans les DEV et faire une API propre (et standard entre OS) pour comme avec secomp et pledge, que l'appli réduire elle même son angle d'attaque. Ce sont les développeurs qui connaissent souvent le mieux celle-ci (et c'est plus facile à maintenir dans une même branche git).
Bref, les restrictions via l'OS comme vous le faites sont bien mais peu utilisée… car je pense trop éloigné de l'arbre de développement des codes.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 2.
et si vous voulez controller les listes de privilèges que vous donnez à vos développeurs? Par exemple, un développeur construit une solution sur un serveur, l'administrateur du serveur souhaite lui donner une partie des privilèges pour tester sa solution sur le serveur, mais pas tous les privilèges. Notre solution peut bien servir dans ce cas.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Sytoka Modon (site web personnel) . Évalué à 2. Dernière modification le 06 septembre 2018 à 18:07.
Je suis d'accord. Dans le cas que vous dites, cela peut marcher.
En pratique, des dev web vont vouloir être "root" via par exemple l'utilisation de conteneur genre docker. De plus en plus, cela va s’appuyer sur de l'intégration continue lié à par exemple gitlab…
Bref, c'est intéressant comme approche mais je crains que cela ne soit pas super utilisé.
Un truc que j'aimerais faire (simplement) est un rsync distant en mode readonly. Genre
rsync -av toto@server1:/etc /tmp/etc
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 3.
Il existe le privilege cap_dac_override que vous pouvez donner à votre utilisateur « toto » en précisant la commande rysync avec les options associées. Maintenant cap_dac_override permet de tout faire (read,write, execute) mais uniquement dans le dossier /etc. Nous ne pouvons pas limiter à readonly car les privileges Linux ne sont pas assez fines, contrairement à d’autres systèmes comme Solaris qui possède des privileges fines et permettent de réaliser ce que vous demandez.
Une amélioration du kernel à ce niveau est nécessaire.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 3. Dernière modification le 07 septembre 2018 à 11:40.
Je reformule ma réponse. En effet, Linux possède le capability CAP_DAC_READ_SEARCH. Ce privilège permet uniquement de lire les fichiers. Donc vous pouvez éditer le fichier de configuration capabilityRole.xml de la manière suivante:
Apres l'utilisateur toto doit utiliser la commande suivante: sr -r role1 -c "rsync -av toto@server1:/etc /tmp/etc"
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ok, merci pour l'exemple. On voit rapidement que le même fichier en YAML serait bien plus lisible mais l'idée générale est effectivement déjà là.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Aujourd'hui si on a besoin de droit spéciaux, on utilise docker.
"La première sécurité est la liberté"
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Donc tu lances docker dans un docker lui même lancé dans un docker … ;-)
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
On peut ajouter que dans le monde linux il n'y a pas que les administrateurs et les utilisateurs. Il y a ceux qui font la distribution, et c'est eux qui ont toutes les billes pour mettre ses restrictions en place. L'approche de pledge semble bien plus facile à mettre en œuvre industriellement que l'approche par utilisateur.
Je rajouterais qu'il manque des privilèges user qui serait sympa : impossible de faire .. pour sortir d'un répertoire de lancement, n'ouvrir que les fichiers créés par l'application en question et rien d'autre, ne pas pouvoir lire des fichiers locales, mais parcourir les répertoires, et écrire dedans si on veut. On pourrait même imaginer que le shell détecte les fichiers données en ligne de commande et donne l'accès uniquement à eux.
"La première sécurité est la liberté"
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Il manque aussi l'interdiction de supprimer un fichier dans un dossier. Le droit w sur le groupe est beaucoup trop vague.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 6. Dernière modification le 07 septembre 2018 à 01:58.
Je viens de voir votre readme. La seule chose que je peux vous dire, c'est que vous vous embêtez vraiment beaucoup à définir des rôles, utiliser les capacités Linux, et tout un tas de choses compliquées pour au final remplacer
pledgeetdoas. Tout votre exemple sur le script python autorisé à démarrer à partir de l'utilisateur awazan de lancer son serveur sur le port 80 revient à autoriser une personne à lancer une application avec certains paramètres, et c'est pratiquement tout. Donc vous demandez aux administrateurs de créer des fichiers XML pour décrire des rôles qui auront des droits, des utilisateurs qui pourront avoir ces rôles et les applications qu'ils pourront lancer avec en plus les paramètres autorisés.Voici le même exemple avec
pldege(voir pledge(2)) etdoas(voir doas.conf(5)) :Dans le fichier
/etc/doas.conf:Et voilà… alors certes, vous pouvez toujours trouver des arguments un peu pointus pour montrer que cela n'est pas 100% équivalent, mais on en est vraiment pas loin, tout en ayant une bien moins grande complexité et donc en ayant bien plus de chances d'être effectivement intégré sur de vrais systèmes en production (ce qui est le cas pour tous les systèmes OpenBSD depuis plusieurs années maintenant).
Le second exemple que vous donnez implique de ne pas pouvoir faire du LD_PRELOAD, ce qui est déjà pris en compte par mon exemple de fichier
doas, tout simplement parce qu'on doit préciser explicitement viakeepenvsi nous souhaitons garder les variables d'environnement de l'utilisateur au lancement de la commande. C'est un fonctionnement par défaut qui me paraît complètement raisonnable, et sûr par défaut.Votre troisième exemple indique qu'il faut actuellement utiliser des commandes compliquées pour injecter des capacités dans le binaire des applications, puis ces privilèges sont supprimés dès que le binaire change, et donc votre solution apporte une certaine stabilité. Oui, comme
doas.Du coup, même en ayant creusé votre proposition, je ne peux que vous encourager à regarder ce qui est fait côté OpenBSD. C'est de loin pour moi un exemple du meilleur de ce qui se fait dans le domaine.
PS: j'ai l'impression que votre travail est lié à une publication scientifique. Je suis sincèrement désolé de voir à quel point vous avez travaillé pour arriver au final à moins bien que ce qui est déjà fait. Certes, c'est externe à l'environnement Linux, mais vous auriez sans doute pu vous en inspirer… bref. Je compatis. Moi aussi je suis dans le domaine et je ne fais pas toujours des articles intéressants. Courage pour la suite.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 2.
Je crains que votre solution ne suffit pas de protéger complètement votre OS. En effet, la configuration de la commande doas vérifie uniquement que l'utilisateur ne va pas passer au script une valeur différente à 80. Rien n'interdit par contre l'utilisateur awazan d'ouvrir un port qui est différent de 80. Par ailleurs, la configuration doas permet au utilisateur awazan de récupérer les privilèges root pour exécuter ce script. Je me demande donc si l'utilisateur awazan n'aura pas la possibilité de créer un autre processus et changeant les arguments de pledge pour pouvoir appeler d'autres syscall..(à tester).
Je pense que vous avez toujours du mal à comprendre que pledge et les separation des privilèges sont des solutions complémentaires. Je vous propose de regarder cette video qui est justement faite par OpenBSD sur la complémentarité de ces deux solutions.
https://www.youtube.com/watch?v=a_EYdzGyNWs
PS: Ma solution ne permet toujours pas de vérifier si l'utilisateur a vraiment ouvert le port 80 ou un autre port. Simplement, si vous avez lu la section to "do list" vous verrez que nous comptons modifier le kernel de Linux pour couvrir cet aspect.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 3.
Soyons d'accord sur ça : non, aucun programme actuel ne vérifie ce que vous souhaitez vérifier avec votre projet. Si je grossis un peu le trait (dites-moi si je me trompe, qu'on soit définitivement d'accord sur la question), votre projet est d'intercepter tous les appels systèmes pour vérifier à la fois si ce sont des appels autorisés, et les paramètres qui y sont passés. Au final oui, vous allez bien plus loin que ce qui existe. Mais je vois 2 problèmes majeurs : les outils (et méthodes) actuels se rapprochent d'une vérification à gros grain mais qui couvre une (très) bonne partie des problèmes, et la complexité pour décrire des autorisations.
Revenons sur vos exemples.
Concernant les ports ouverts, effectivement, pledge et doas ne peuvent pas vérifier cela. En revanche c'est le travail de
pf(le pare-feuxpacket filter), et il le fait très bien, il va même au delà de ce que vous souhaitez faire : vous pouvez préciser les messages qui sont ou pas accepter (est-ce qu'il doit accepter d'ouvrir des connexions TCP à partir de ce port, ou seulement en recevoir ? Est-ce de l'UDP ? SCTP ? Quelle taille de buffer ? …).Pour l'exemple que vous donnez d'un subprocess qui serait appelé par un programme d'awazan, et que ce programme aurait été modifié par awazan pour y ajouter des éléments dans pledge, c'est au final très peu réaliste. En réalité, il est hors de question de donner des droits root à un simple utilisateur sur un programme de l'utilisateur. C'est un non sens, littéralement une faille de sécurité.
Comme nous l'avons vu pour l'instant, les exemples couvrent l'usage du réseau, ce qui est important également c'est l'usage du système de fichiers, et pour ça la séparation de privilèges (que j'ajouterai volontiers : amorcée par le projet OpenBSD…) et le
chroot. Rien qu'avec les outils que je viens de citer, on sait gérer en grande partie le réseau (quels sont les ports qui peuvent être ouverts), on ne laisse pas une application ouvrir des fichiers au hasard sur le système (elle est contrainte dans une racine séparée), et on ne laisse pas un simple utilisateur s'octroyer des droits (hors de question qu'on laisse des droits root sur un programme utilisateur, on donne le droit à un utilisateur de lancer un programme root avec des paramètres prédéfinis).On peut dire également que votre projet permet à un simple utilisateur de lancer son propre programme de manière sûre… si on a fait un gros travail en amont pour contraindre le programme qu'il veut lancer à ne faire que ce dont on a décidé. Effectivement, vous pouvez aller jusqu'à préciser à la fois qu'un programme en particulier sera utilisé par un utilisateur en particulier et qu'il n'aura pas le droit d'ouvrir autre chose qu'un port en particulier. Mais tout ceci reste laborieux, et en pratique les paramètres vont changer très souvent. Là où les outils actuels font bien leur travail est qu'ils maintiennent une balance intéressante entre le temps pris pour l'administration/développement, et les vérifications qui sont faites. C'est simple, rapide à implémenter, et du coup c'est utilisé.
Ensuite, concernant la complexité de description des autorisations. Vous avez fait un travail pour alléger l'écriture des différentes règles en définissant des rôles à des utilisateurs et des groupes, ce qui est un moyen assez simple de regrouper des instructions qui ont un même sens sémantique. Ça ne va pas assez loin, c'est même bien trop simpliste. Les exemples qu'on peut voir sont également simplistes, et je ne vois pas votre projet fonctionner pour de grosses applications, il y a un manque d'expressivité. Je ne peux que vous conseiller de regarder la syntaxe de
pfdans la FAQ OpenBSD pour vous en inspirer.Pour que votre solution soit utilisable, il faudrait selon moi regrouper les appels système, pouvoir donner des indications "laxistes" où on dirait "vérifie que le programme X n'ouvre que le port Y, mais je m'en fous de tout autre paramètre lié au réseau". Sinon on sera obligé d'écrire des tonnes d'instructions pour couvrir tous les appels qui sont fait. Par exemple, si un programme a besoin de lire et écrire des fichiers, il va être un peu pénible de devoir faire une instruction pour préciser tous les appels de
openavec tous les fichiers (ou alors il faut s'inspirer destablesdanspf). Bref, regardez la syntaxepf, il y a déjà tout ce que vous voulez : destablespour regrouper des capacités, utilisateurs, groupes, des instructions de blocage ou acceptation (block,pass) et la possibilité de dire "tout sauf" (via '!') ce qui est pratique, desmacrospour simplifier la lecture, des listes, desancrespour donner la possibilité à une application externe d'ajouter des instructions à la volée…Allez, je ne résiste pas à donner un exemple :
table <webusers> { awazan, toto } # table = liste qui peut être màj à la volée via une commande
cap_net_web = "cap_net_bind_service port { 80, 443 }"
progweb = "/usr/local/sbin/webfail.py"
cap_fs = { toutes les capacités liées au système de fichiers }
pass cap_net_web to <webusers> prog progweb
pass log cap_fs to <webusers> prog progweb label "fs web" # autorise et log tous les accès aux fichiers
block # bloque tout ce qui n'est pas explicitement autorisé au dessus
Bon, si le projet se dessine au final comme ça, il m'intéresse. ;) Là il commencerait à devenir intéressant dans la pratique (pour le debug principalement).
PS: Vous ne pouvez pas le savoir… mais il y a un commentaire que j'ai posté il y a plus d'un an sous cette vidéo… :-D
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 2.
Je pense que on va arriver à se mettre d'accord. Si openbsd n'a pas implémenté le brouillon POSIX, mon travail n'a aucun intérêt dans OpenBSD. Par ailleurs, mon objectif ne consiste pas à filter les syscalls, il existe bien d'autres solutions qui font ce travail parfaitement comme par exemple Linux Extended BPF.
Mon objectif est de définir une approche de distribution des privilèges root dans les OSs qui ont implémenté le brouillon POSIX. Je vous donne un exemple en reprennat le syntaxe de votre propre exemple sur pf. Nous avons dans Linux le privilège cap_dac_override qui permet à celui qui le possède de contourner toutes les permissions. Maintenant, quand je donne ce privilège à quelqu'un j'aimerais lui donner ce privilège uniquement pour contourner les permissions sur certains dossiers mais pas tout le système. Ainsi, mon système doit permettre à l'administrateur de préciser les privilèges, les utilisateurs et les ressources sur les quelles ces privilèges seront appliqués. le syntaxe pf ce que je veux faire est le suivant:
table { awazan, toto } #
cap_dac_override_personal_documents = "cap_dac_override { /home/user/awazan}"
progbackup = "/usr/bin/backup_program"
pass cap_dac_override_personal_documents to prog progbackup
block # bloque tout ce qui n'est pas explicitement autorisé au dessus
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 1.
Je pense que pour mieux comprendre et répondre à ce que vous voulez faire, il me faudrait l'accès au draft. Malheureusement je n'ai pas de compte sur opengroup.org.
J'ai zieuté un peu "Operating System Structures to Support Security and Reliable Software" (1976), j'ai pas eu le courage de lire les 37 pages mais je n'ai pas l'impression que cela reflète parfaitement ce que vous souhaitez faire de nos jours. J'en ai retenu un système un peu compliqué, dont les auteurs sont d'accord pour dire que des options de sécurité dans les compilateurs pourraient faire une partie du job.
Du coup, je ne peux me baser que sur les exemples que vous donnez, et qui me semblent trop éloignés de la réalité pour être utiles en pratique. Mais soit, je me demande ce à quoi cela ressemblera à l'avenir, et je vois l'utilité qu'on pourrait en avoir (même si c'est éloigné de l'objectif qui est annoncé).
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 1. Dernière modification le 08 septembre 2018 à 14:57.
Je pense qu'il faut lire la documentation de Linux sur les capabilities. Sinon vous avez aussi des articles sur Internet qui parlent de ce sujet. Nous donnons plusieurs références dans notre page Github.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Patrick Lamaizière (site web personnel) . Évalué à 3.
Bonjour,
PF utilise une politique (assez nulle ama) de last matching rule, sauf si quick est spécifié. Ces règles là, en bref, ça bloque tout.
(je dis ça…)
les pixels au peuple !
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 1.
Effectivement. J'ai écris cela pour la concision, montrer comment on pourrait faire ça avec cette syntaxe. Le reste est du détail technique.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par samerw . Évalué à 1.
Il semble que OpenBSD n'a pas implémenté POSIX draft 1003.1e dans son kernel. Si cela est vrai, alors OpenBSD adopte le modèle traditionnel d'administration où tous les pouvoirs sont aux mains de l'utilisateur root. Pledge permet d'améliorer la situation mais je me demande du coups comment être sûr que l'utilisateur n'a pas ouvert par exemple le port 81 au lieu de 80 dans OpenBSD?
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 3.
Seul root a le droit d'ouvrir un port < 1024. Dans la pratique je n'ai jamais, en 15 ans d'administration système, eu besoin d'ouvrir un port < 1024 pour utilisateur. Ce qui est fait en revanche, c'est que root lance un programme qui se sépare en deux pour gérer correctement la séparation de privilèges, avec d'un côté un programme qui gère le réseau et les appels systèmes en tout genre, et un programme qui n'a droit qu'à très peu de choses, avec un pledge qui lui coupe presque tout et est dans une racine séparée.
OpenBSD ne part pas du principe qu'on a le droit d'ignorer le code, le projet part au contraire du principe qu'il faut être très vigilent sur le programme qu'on écrit, qu'il faut faire activement des relectures même si on implémente des tas de parades dans le noyau pour contrer des attaques potentielles. Les deux sont complémentaires, et on ne peut pas prétendre gérer la sécurité si on ne fait pas les deux. S'il y a eu si peu de failles sur ce système en plus de 20 ans d'existence, ce n'est pas le fruit du hasard. Les mots clés sont : relecture et sécurité pro-active (séparation de privilèges, pledge, W^X, pageguard, diverses options de compilation…).
Si on a un programme dangereux à faire tourner, on peut toujours le mettre dans un chroot et le lancer via un autre utilisateur. On peut aussi s'amuser à lui créer une interface réseau pour qu'il fasse sa tambouille dessus, sous linux il faut voir les
netnsavecip. Mais à aucun moment le réflexe est de lui donner tous les droits sur le système, il est contraint, au pire dans un sous-système minimaliste (vraiment minimaliste, un chroot n'a besoin de rien du tout, limite une copie de/etc/resolv.confet peut-être un ou deux autres fichiers vite-fait).Implémenter de la sécurité pro-active ne doit pas dispenser d'écrire du code en respectant les standards de sécurité. Et si on les respecte, il ne reste finalement que peu d'erreurs à intercepter, et elles resteront difficiles à analyser même avec votre solution. Donc oui c'est un complément, et le commentaire que je vous ai donné plus haut montre en quoi votre projet peut être intéressant (voir l'exemple de syntaxe
pfadaptée à votre outil) avant tout pour voir ce qui se passe en historisant les appels système.PS: Bon, mine de rien j'ai passé pas mal de temps à argumenter… donc soit on discute authorship soit je pars finir ma thèse ! :-D
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 1. Dernière modification le 07 septembre 2018 à 17:42.
Réponse un peu plus directe à votre question : on ne le fait pas. On vérifie que le programme en amont pour vérifier qu'il ouvre bien le port qu'on lui demande, et c'est tout. Un programme va, dans les cas observés et selon mes connaissances, se lancer en ouvrant les ports dont il a besoin puis pledge. S'il n'a pas ouvert les bons ports avant pledge, c'est une erreur de programmation mineure et évidente, et après il ne peut de toutes façons plus ouvrir de port. Si on parle réseau, de toutes manières il y a de fortes chances pour qu'on puisse gérer ça avec
pf, même s'il ne fait pas le lien avec le programme ni l'utilisateur qui a lancé le programme.S'il y a une place pour votre projet sur de vrais système, je ne considère pas nécessairement que ce soit lié à 100% à la sécurité, mais surtout pour la surveillance des programmes et leur debug. J'ai peur qu'il soit trop complexe de définir correctement les droits sans être soit trop laxiste, soit trop stricte, la balance est compliquée à obtenir (mais c'est mon avis, je serai ravis d'avoir tort).
En revanche, si je me souviens bien, les capacités sont gérées non pas au niveau du programme seul, mais aussi de ses fils. Ça c'est intéressant, toujours pour le debug en analysant ce qui se passe dans un environnement de test par exemple.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je me demande si sous linux, il n'est pas déjà possible de limiter l'exploitation du système de fichier avec les namespaces et chroot.
"La première sécurité est la liberté"
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 1.
De ce que j'en comprends, il est possible de sortir de son chroot sous linux, et le développeur est sensé ne pas considérer chroot comme une sécurité. Je me demande ce qu'un namespace peut apporter à ça. Sous OpenBSD il y a depuis peu la fonction
unveilqui limite l'accès au système de fichiers.[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il y a un name space pour mount, il me semble qu'il y en a une capabilities pour avoir accès au device (mkdevice, qui permettait de sortir de chroot).
Je pense qu'il manque juste l'outil qui recréait un mouting point avec les bons fichiers ou un device specific à mounter qui filtre les fichiers.
"La première sécurité est la liberté"
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par BAKfr . Évalué à 1.
Je ne l'ai jamais utilisé, mais il me semble que LXC en mode application fait quelque chose de ce genre là.
Il y a aussi Flatpak qui est prometteur: une application flatpak arrive sous forme d'archive contenant un système de fichier, dans lequel tout est en lecture seule sauf certains dossiers spécifiques.
Pour accéder au système de fichier réel, une application a deux possibilités:
On peut donc créer un paquet flatpak de façon à ce qu'une application ait un accès seulement vers une liste de dossiers spécifique (au hasard,
~/.local/share/my_appet~/.config/my_app), et qu'elle soit obligée de passer par une boite de dialogue gérée par le système pour demander à ouvrir un fichier spécifique.D'ailleurs, il y a pas mal de jeux piratés pour Linux qui utilisent flatpak pour la distribution, et qui s'assure que les jeux ne mettent pas de fichier en vrac dans le dossier home. Les fichiers sont "redirigés" au bon endroit via un système de lien symbolique dans l'archive flatpak.
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par claudex . Évalué à 3. Dernière modification le 26 septembre 2018 à 09:09.
Sous Linux, il y a
firejailqui te permet de facilement contrôler les namespace pour donner accès à certains bout du filesystem ou de limiter certains bouts en ro.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu . Évalué à 3. Dernière modification le 26 septembre 2018 à 14:15.
Faudrait que je me penche sur le code de
firejail, parce que son utilisation (avecfirefox) m'a apporté quelques problèmes.Déjà, lancer firejail sur firefox ne permet pas de ^Q une seule instance de firefox, ça coupe tout, donc qu'est-ce qui se passe derrière firefox pour continuer à toucher aux autres instances de firefox ? Juste que firefox est mal codé (c'est totalement une option) ? Comment se passe la discussion entre instances, et peut-elle être empêchée par firejail ?
Ensuite, j'ai eu des problèmes de son : plus d'audio, même en allant désactiver puis réactiver la sortie avec alsamixer, et pulseaudio ne se lançait plus du tout. Je n'ai vraiment aucune piste pour comprendre ce qui s'est passé.
Du coup, ça me semble moins pratique, et un peu plus cryptique que lancer firefox derrière un
ssh -X toto@localhost.[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par bubar🦥 (Mastodon) . Évalué à 4.
ce qui t'as posé pb n'est pas firejail mais la politique pour firefox de firejail.
# Permissions Android
Posté par Eiffel . Évalué à 5.
Lorsqu'une application Android souhaite, par exemple, accéder à l'appareil photo du mobile il faut qu'elle demande la permission.
Pour demander la permission il faut que son développeur ait inclus dans le manifeste de l'application la demande de ladite permission.
Quelqu'un saurait-il comment est géré dans le noyau ce mécanisme de permission ? Est-ce propre à Android (donc des modifications que Google a apporté à Linux) ou bien ce mécanisme existe-t-il déjà dans Linux ?
Quelles sont les différences entre la proposition de l'article et les permissions Android ?
[^] # Re: Permissions Android
Posté par samerw . Évalué à 0.
Malheureusement je ne connais pas assez Android pour répondre à votre question.
[^] # Re: Permissions Android
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
De ce que j'en ai compris, sur Android, les permissions ne sont pas géré par le noyau mais par Android. Les applications n'ont pas accès au système (rappel: elles sont en Java), mais à un ensemble d'API (qui elles, appellent les api systèmes). Et une application est dans une sandbox. De ce fait, quand une application fait appelle à une API, Android vérifie que l'application a le droit d'appeler cette API, en se référant aux permissions données par l'utilisateur (que ce dernier a indiqué à l'installation ou au moment de l'appel à la fonctionnalité). Si c'est pas bon, ça échoue.
Bref, c'est la couche Android qui fait "firewall", pas le noyau.
[^] # Re: Permissions Android
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 07 septembre 2018 à 16:05.
De ce que moi j'ai compris de Android…
Il y a deux niveaux de permissions à considérer sous Android :
- les permissions de la couche Android (accès aux API, messages etc.). C'est un système de permission dédié
- les permissions POSIX, et là c'est bien du classique : chaque appli a son user:group dédié
Oui, c'est du Java (mais pas que d'ailleurs), mais ça reste un process unique vu du noyau : le JVM est bien instanciée pour chaque appli, et a donc des droits POSIX dédiés.
Pour illustrer :
Une appli n'aura jamais le droit de parler directement au périphérique GPS (elle devrait être root, ce n'est évidemment pas le cas), elle doit donc passer par l'API Android (et donc avoir des permissions Android).
Mais une appli qui écrit dans le répertoire utilisateur (photos, sauvegarde des préférences utilisateurs ou je ne sais quoi) aura le droit d'écriture, sans avoir le droit d'écrire ni de lire dans le répertoire d'une autre appli (permissions Linux).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Permissions Android
Posté par oinkoink_daotter . Évalué à 3.
Est-ce que ce sont des permissions unix habituelles ou des ACL ?
Je vois mal comment on peut gérer finement des permissions type telle appli à un accès RW à tes données, mais telle appli non c'est juste du R, avec le modèle UGO classique.
Ou alors j'imagine un modèle batard ou l'accès niveau FS est "tout ou rien" niveau R/W et la VM filtre les appels Read et Write ?
[^] # Re: Permissions Android
Posté par bubar🦥 (Mastodon) . Évalué à 8. Dernière modification le 08 septembre 2018 à 00:37.
c'est ce qui m'intéresse le plus en tant qu'utilisateur : une gestion plus fine des "droits" (entre guillemets et en italique pour insister sur le côté "vue utilisateur" et non pas sur les droits unix). Par exemples :
C'est une partie du point de vue d'Android il me semble …
Et une partie de la réponse ne se situe pas dans les droits UGO mais dans ceux-ci + une grosse gestion d'uid et de guid côté système + le concept de déclaration de racine et d'isolation (dont l'implémentation pour arriver au résultat peut être diverse : chroot, sandbox selinux, usage des namespaces, utilisation de points de montage bind à la demande, ..)
Il y a pas mal d'arguments contre ça, d'un point de vue système et kiss, mais il y a aussi pas mal d'arguments pour, et à l'heure où le soucis central c'est l'accès à nos données par des tiers sur le réseau via des apps que j'installe, il est peut être tant de se dire qu'en 2018 il est complètement con que les navigateurs aient accès par défaut aux clefs privées dans .ssh.
[^] # Re: Permissions Android
Posté par totof2000 . Évalué à 2.
Pourquoi ? Quid de ce genre de truc ?
Celà dit je comprends le raisonnement (avoir la possibilité de l'interdire par défaut mais de l'ouvrir si besion), mais l'idée est que potentiellement, tu peux en avoir besoin.
[^] # Re: Permissions Android
Posté par groumly . Évalué à 4. Dernière modification le 09 septembre 2018 à 20:55.
Android, je sais pas, mais de ce que j’en comprends, iOS fait de l’IPC (xpc en parlance Apple) pour tout/la plupart de ce qui requiert des permissions.
L’implémentation repose sur des mach messages, et passe donc par le kernel. Ça paraît assez simple pour des trucs genre location etc, pas sûr de comment ça marche pour des services lourds en données, genre photos.
Bref, l’idée de base c’est que le process demeure 100% sandboxé. L’appli demande les permissions au daemon, qui va rendre, via le window manager, la pop up de confirmation (out of process donc). Une fois confirmé, la communication xpc peut continuer entre les 2.
L’appli reste donc 100% sandboxée et non privilégiée, ce qui est plutôt cool. Ya toujours le système de root, donc c’est techniquement possible de passer root et faire des choses affreuses au système (mais ça reste difficile à cause de la sandbox).
Le truc c’est que ça marche uniquement parce que c’est un système mono utilisateur, et donc l’humain est de confiance, c’est les applis qui ne le sont pas, le contexte est donc très différent de ce qui est discuté ici (les applis sont de confiance, mais pas les humains).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Super Quoi ? :>
Posté par Melodie (site web personnel) . Évalué à 5.
rumeur persistante issue de l'égo d'un internaute probablement oublié
"su" pour "substitute user", "sudo" pour "substitute user and do". Pour référence, par exemple, le Jargon Français de Roland TRIQUE : http://jargonf.org/wiki/su - http://jargonf.org/wiki/sudo
CQFD !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.