Non. Des solutions pourront être mises en place dans l'avenir pour fournir cette fonctionnalité (comme je l'ai évoqué dans un autre commentaire); mais pour l'instant, ça ne marche pas. C'est incontestablement une limitation de mon système. J'estime simplement que les bénéfices tirés de l'accroissement de la sécurité en valent la peine.
Ok ben en tant que gros utilisateur de vim, c'est rédhibitoire. Pour un petit utilisateur, je comprendrai que ça change peu, mais quand je développe, je commence en général en ouvrant 1 ou 2 fichiers que je pense être ma cible. Puis je me rends compte que j'ai besoin de vérifier l'API et l’implémentation de tel autre, puis tel autre, etc. J'arrive facilement a une dizaine de fichiers dans des tabs vim. Et je ne vais certainement pas fermer vim, puis le rouvrir avec un fichier de plus sur la ligne de commande toutes les 2 minutes (surtout que ce faisant, je perds l'historique de vim pour mes undo en cas d'erreur, mes marks, registres, etc.!). Et puis des fois, j'ouvre un fichier pour le regarder 2 min, et le fermer immédiatement. Devoir fermer/rouvrir vim pour ça serait vraiment contre-productif. Enfin tout ça pour dire que pour moi cette sécurité ne vaut absolument pas la perte de fonctionnalité. :p
En fait, non. Dans ce cas précis, tu as passé http://XXX sur la ligne de commande de ton lanceur, ce qui permet de comprendre ton intention d'accéder au réseau, par conséquent, le lanceur fournirait à cette instance de vim l'accès requis.
Ok mais je suis sur que vim peut avoir d'autres utilisations du réseau en dehors de la ligne de commande. J'ai l'impression que dans ton OS, tout est trop lie a la ligne de commande (et je dis ça, pourtant je lance plein de choses en lignes de commande moi-même, au moins tout ce qui est en rapport avec mes activités de développement!). C'est peut-être ça le problème. Ne devrais-tu pas trouver un système plus adaptable a diverses situations? Par exemple, une application peut annoncer quel type de droits elle nécessite et l'OS peut les accorder au cas par cas (mais bien sur ça demande de préparer une telle liste pour chaque logiciel, ce qui peut être une part du packaging par exemple; et certes les devs paresseux pourraient juste demander tous les droits a l'OS, comme ça arrive dans les smartphones avec ce type de sécurité, et donc on en perd le sens)? Ou bien quand un droit un peu particulier (accès a un nouveau fichier en cours d’exécution? Accès au réseau?) est requis, l'OS popup une question a l'utilisateur qui peut donner le droit ou non selon que ça correspond a ce qu'il est en train de faire.
Ex:
- l'utilisateur veut ouvrir un fichier dans un vim déjà lance :tabopen fichier.c
- l'OS lui demande "le programme 'vim' veut accéder a la ressource fichier 'fichier.c'. L'autorisez-vous?" [oui] [non]
Par contre si au milieu de nulle part, vim demande un accès réseau (alors qu'il a rien fait qui justifie cela), l'utilisateur est alerté qu'y a un truc pas net et peut rechercher si y a pas un programme espion chez lui qui tenterait de faire quelque chose avec le réseau en passant par vim.
Bon c'est un peu le fonctionnement de certains firewall/antivirus, et je sais que ça peut être très chiant parfois (genre ça demande 50 trucs que l'utilisateur comprend pas quand on veut juste lancer un prog). Mais peut-être aussi cela peut-il être fait de manière plus intelligente que ces firewalls?
Dans tous les cas, je pense que limiter massivement toutes les fonctionnalités intéressantes (et basique comme ouvrir des fichiers durant exécution!) des programmes ne peut être la bonne solution! A long terme, tu devras vraiment trouver quelque chose pour aller plus loin, tout en restant dans une logique de sécurité (enfin ce n'est qu'un avis rapide, je n'ai certainement pas toutes les cartes en main non plus).
En revanche, avec son split dans vim et son ouverture d'un second fichier, l'utilisateur commettrait effectivement une erreur qui permet la propagation de l'attaque. Et c'est faisable, mais pas de la façon dont tu l'envisages : il faudrait passer à vim deux fichiers sur sa ligne de commande, et ensuite ouvrir le second dans le split.
En fait c'est bien ce que j'envisageais. Comme je disais plus haut, j'utilise vim massivement comme un éditeur multi-fichiers (ce qu'il est, brillamment même!). Soit parfois en split, ça c'est surtout quand y a deux fichiers vraiment très proches que je veux comparer (souvent avec le mode "diff" de vim); mais aussi souvent dans des tabs vim. Travailler ainsi est très différent de travailler dans des instances séparées de vim, notamment pour le copier/couper/coller (je sais qu'on peut aussi travailler dans des instances de vim séparées, et partager des buffers, mais c'est moins pratique...).
Quoiqu'il en soit, je ne dirais pas forcement que c'est une erreur de l'utilisateur d'ouvrir plusieurs fichiers pour s'aider dans son travail. Et même si c'en est une (oui en effet, il pourrait vérifier séparément son fichier venant d'une source plus douteuse d'abord, ou utiliser des copier-coller système, etc.), ben on est humains. On fait ce genre d'erreur, et c'est tant mieux parce que sinon la vie serait vachement chiante. Effectivement nombre d'attaques pourraient être contrées si le gars est plus méticuleux/méthodique et vérifie chaque variable une par une, mais si on se met a faire cela, la vie est un enfer (un peu comme des TOCs, comme le gars qui va se laver les mains 100 fois par jour. Certes il risque moins d’être malade que moi, mais je préfère de temps en temps chopper un rhume que de vivre une vie entière dans la peur des microbes).
Enfin voila, tout ça pour dire qu'au nom de la sécurité a tout prix, si la vie devient horrible, ben je suis pas sur que ça vaut le coup.
Mais ce n'est qu'un avis sans réellement avoir teste. Je te souhaite tout de même bonne chance, et si t'as des nouvelles d'avancement du projet, n’hésite pas a reposter. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Si je comprends bien on ne peut pas modifier un fichier sur le disque
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Annonce : Manux 0.0.1. Évalué à 3.
Salut,
Ok ben en tant que gros utilisateur de vim, c'est rédhibitoire. Pour un petit utilisateur, je comprendrai que ça change peu, mais quand je développe, je commence en général en ouvrant 1 ou 2 fichiers que je pense être ma cible. Puis je me rends compte que j'ai besoin de vérifier l'API et l’implémentation de tel autre, puis tel autre, etc. J'arrive facilement a une dizaine de fichiers dans des tabs vim. Et je ne vais certainement pas fermer vim, puis le rouvrir avec un fichier de plus sur la ligne de commande toutes les 2 minutes (surtout que ce faisant, je perds l'historique de vim pour mes undo en cas d'erreur, mes marks, registres, etc.!). Et puis des fois, j'ouvre un fichier pour le regarder 2 min, et le fermer immédiatement. Devoir fermer/rouvrir vim pour ça serait vraiment contre-productif. Enfin tout ça pour dire que pour moi cette sécurité ne vaut absolument pas la perte de fonctionnalité. :p
Ok mais je suis sur que vim peut avoir d'autres utilisations du réseau en dehors de la ligne de commande. J'ai l'impression que dans ton OS, tout est trop lie a la ligne de commande (et je dis ça, pourtant je lance plein de choses en lignes de commande moi-même, au moins tout ce qui est en rapport avec mes activités de développement!). C'est peut-être ça le problème. Ne devrais-tu pas trouver un système plus adaptable a diverses situations? Par exemple, une application peut annoncer quel type de droits elle nécessite et l'OS peut les accorder au cas par cas (mais bien sur ça demande de préparer une telle liste pour chaque logiciel, ce qui peut être une part du packaging par exemple; et certes les devs paresseux pourraient juste demander tous les droits a l'OS, comme ça arrive dans les smartphones avec ce type de sécurité, et donc on en perd le sens)? Ou bien quand un droit un peu particulier (accès a un nouveau fichier en cours d’exécution? Accès au réseau?) est requis, l'OS popup une question a l'utilisateur qui peut donner le droit ou non selon que ça correspond a ce qu'il est en train de faire.
Ex:
- l'utilisateur veut ouvrir un fichier dans un vim déjà lance :tabopen fichier.c
- l'OS lui demande "le programme 'vim' veut accéder a la ressource fichier 'fichier.c'. L'autorisez-vous?" [oui] [non]
Par contre si au milieu de nulle part, vim demande un accès réseau (alors qu'il a rien fait qui justifie cela), l'utilisateur est alerté qu'y a un truc pas net et peut rechercher si y a pas un programme espion chez lui qui tenterait de faire quelque chose avec le réseau en passant par vim.
Bon c'est un peu le fonctionnement de certains firewall/antivirus, et je sais que ça peut être très chiant parfois (genre ça demande 50 trucs que l'utilisateur comprend pas quand on veut juste lancer un prog). Mais peut-être aussi cela peut-il être fait de manière plus intelligente que ces firewalls?
Dans tous les cas, je pense que limiter massivement toutes les fonctionnalités intéressantes (et basique comme ouvrir des fichiers durant exécution!) des programmes ne peut être la bonne solution! A long terme, tu devras vraiment trouver quelque chose pour aller plus loin, tout en restant dans une logique de sécurité (enfin ce n'est qu'un avis rapide, je n'ai certainement pas toutes les cartes en main non plus).
En fait c'est bien ce que j'envisageais. Comme je disais plus haut, j'utilise vim massivement comme un éditeur multi-fichiers (ce qu'il est, brillamment même!). Soit parfois en split, ça c'est surtout quand y a deux fichiers vraiment très proches que je veux comparer (souvent avec le mode "diff" de vim); mais aussi souvent dans des tabs vim. Travailler ainsi est très différent de travailler dans des instances séparées de vim, notamment pour le copier/couper/coller (je sais qu'on peut aussi travailler dans des instances de vim séparées, et partager des buffers, mais c'est moins pratique...).
Quoiqu'il en soit, je ne dirais pas forcement que c'est une erreur de l'utilisateur d'ouvrir plusieurs fichiers pour s'aider dans son travail. Et même si c'en est une (oui en effet, il pourrait vérifier séparément son fichier venant d'une source plus douteuse d'abord, ou utiliser des copier-coller système, etc.), ben on est humains. On fait ce genre d'erreur, et c'est tant mieux parce que sinon la vie serait vachement chiante. Effectivement nombre d'attaques pourraient être contrées si le gars est plus méticuleux/méthodique et vérifie chaque variable une par une, mais si on se met a faire cela, la vie est un enfer (un peu comme des TOCs, comme le gars qui va se laver les mains 100 fois par jour. Certes il risque moins d’être malade que moi, mais je préfère de temps en temps chopper un rhume que de vivre une vie entière dans la peur des microbes).
Enfin voila, tout ça pour dire qu'au nom de la sécurité a tout prix, si la vie devient horrible, ben je suis pas sur que ça vaut le coup.
Mais ce n'est qu'un avis sans réellement avoir teste. Je te souhaite tout de même bonne chance, et si t'as des nouvelles d'avancement du projet, n’hésite pas a reposter. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]