> ce paramètre ulimit (que je ne connaissais pas) pourrait être mis à la valeur qui va bien
Quelles valeurs ?
Par exemple pour la mémoire, on limite à 1Go ?
Et si l'utilisateur lance un programme qui utilise de façon tout à fait légitime 1Go + 1 octet. On fait quoi ?
Quelles valeur pour la consommation cpu par un processus ?
24 h? Ça semble fort raisonnable.
Et si l'utilisateur code une grosse vidéo en 1920x1080 et que ça prend 25 h ? Ben il va virer ulimit et recommencer. Il aura perdu au moins une journée.
Quelles valeur pour la consommation de disque dur ?
Ben oui, il peut y avoir un programme malintentionné qui ne fait que saturer le disque dur. 10 Go ? Trop peu en cette époque de vidéo. 100 Go ? Pourquoi pas. Mais bon, on active quelque chose qu'au bout de 100 Go !!!!
Puis un programme malintentionné n'a pas besoin de 24 h pour faire des dégâts et n'a pas besoin de 1 Go de mémoire vive pour faire des dégâts et n'a pas besoin de 100 Go d'espace disque pour faire des dégâts et n'a pas besoin de se forker 1000 fois pour faire des dégâts.
Donc ulimit comme outil de sécurité c'est assez limité :-)
> pour éviter soit comme il a été dit précédemment qu'une faille de sécu dans un prg permette de lancer un tel fork bomb
C'est un programme type serveur, donc il faut corriger le programme. Et si c'est pour l'aspect DOS, ça ne change pas grand chose car ulimit aura killé le serveur donc on a aussi un DOS.
Je répète pour le 10 millième fois : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK". C'est aussi valable pour un programme. Si un serveur a l'intelligence d'appeler ulimit, capability, setuid(), etc. Très bien.
Qu'un autre programme passe par là au nom du "bien être de l'utilisateur" et se dise "bizarre, ce processus me semble consommer de façon illégitime trop de mémoire, donc je vais le tuer", pas d'accord. Pas d'accord dans un contexte Desktop.
> soit qu'une machine plus ou moins publique soit plantée à cause de cela
Une machine public est une sorte de serveur. Elle est multi-utilisateur même si ce n'est pas simultanement. Il est claire que pour ce type de machine, il faut quelque précautions (quota, etc... cf les cyber café par exemple). Mais faut-il faire peser ses contraintes pour un utilisateur qui installe une Ubuntu pour seul usage et peut-être celui de sa copine ou son copin ?
Je ne crois pas car ça risque d'être plus une source d'emmerde qu'autre chose. Et s'il subit un fock bomb ? Ben il reboote et voilà. Si ça lui arrive 1 fois en 3 ans c'est déjà remarquable. Je ne crois pas qu'il faut s'emmerder avec ça.
C'est claire que si on considère que ces trucs (limiter le nombre de fork, etc...) marche nickel, n'ont pas d'effet de bord, etc, il est claire que quand je dis que c'est de la connerie, je passe pour un abruti profond.
Mais ces systèmes ont des effets de bord. Voir Windows qui a tout un tas de truc dans ce goût. Mais comme ils ont des effets de bords, Windows donne à l'utilisateur la possibilité de les désactiver. Et c'est ce que fait la majorité des utilisateurs, ce qui donc enlève l'intérêt de ces "trucs".
> Je serais plutôt tenté de dire que c'est à l'utilisateur aguerri qui aurait besoin de mettre des valeurs illimitées
Il faut peser le pour et le contre. Mettre des limites est contraignant (par définition). Si c'est seulement pour eviter qu'un utilisateur chez lui reboote ça bécane 1 fois tous les 3 ans car un programme a déconné, je trouve que c'est trop d'inconvénient et il y a aussi le risque que finalement l'utilisateur désactive tout ce qui le limite.
Si c'est sur un serveur qui héberge une centaine de site web professionnel avec des informations confidentiel, etc, c'est claire que même un reboote imprévu n'est pas tolérable même si c'est tout les trois ans et que l'utilisation de ulimit doit être vivement encouragée.
> protègerait 99% des autres.
Protéger de quoi ?
D'un reboot tout les trois ans ?
Un programme mal intentionné n'a pas besoin de se fock 1000 fois pour faire des dégâts.
> Sinon on peut dire également que les distribs linux pourraient laisser le port telnet d'ouvert
Tu parles de donner la possibilité à des personnes externes d'utiliser ta bécane, ça n'a rien à voir. On parle d'utilisateur légitime qui lance un programme.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 3.
Quelles valeurs ?
Par exemple pour la mémoire, on limite à 1Go ?
Et si l'utilisateur lance un programme qui utilise de façon tout à fait légitime 1Go + 1 octet. On fait quoi ?
Quelles valeur pour la consommation cpu par un processus ?
24 h? Ça semble fort raisonnable.
Et si l'utilisateur code une grosse vidéo en 1920x1080 et que ça prend 25 h ? Ben il va virer ulimit et recommencer. Il aura perdu au moins une journée.
Quelles valeur pour la consommation de disque dur ?
Ben oui, il peut y avoir un programme malintentionné qui ne fait que saturer le disque dur. 10 Go ? Trop peu en cette époque de vidéo. 100 Go ? Pourquoi pas. Mais bon, on active quelque chose qu'au bout de 100 Go !!!!
Puis un programme malintentionné n'a pas besoin de 24 h pour faire des dégâts et n'a pas besoin de 1 Go de mémoire vive pour faire des dégâts et n'a pas besoin de 100 Go d'espace disque pour faire des dégâts et n'a pas besoin de se forker 1000 fois pour faire des dégâts.
Donc ulimit comme outil de sécurité c'est assez limité :-)
> pour éviter soit comme il a été dit précédemment qu'une faille de sécu dans un prg permette de lancer un tel fork bomb
C'est un programme type serveur, donc il faut corriger le programme. Et si c'est pour l'aspect DOS, ça ne change pas grand chose car ulimit aura killé le serveur donc on a aussi un DOS.
Je répète pour le 10 millième fois : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK". C'est aussi valable pour un programme. Si un serveur a l'intelligence d'appeler ulimit, capability, setuid(), etc. Très bien.
Qu'un autre programme passe par là au nom du "bien être de l'utilisateur" et se dise "bizarre, ce processus me semble consommer de façon illégitime trop de mémoire, donc je vais le tuer", pas d'accord. Pas d'accord dans un contexte Desktop.
> soit qu'une machine plus ou moins publique soit plantée à cause de cela
Une machine public est une sorte de serveur. Elle est multi-utilisateur même si ce n'est pas simultanement. Il est claire que pour ce type de machine, il faut quelque précautions (quota, etc... cf les cyber café par exemple). Mais faut-il faire peser ses contraintes pour un utilisateur qui installe une Ubuntu pour seul usage et peut-être celui de sa copine ou son copin ?
Je ne crois pas car ça risque d'être plus une source d'emmerde qu'autre chose. Et s'il subit un fock bomb ? Ben il reboote et voilà. Si ça lui arrive 1 fois en 3 ans c'est déjà remarquable. Je ne crois pas qu'il faut s'emmerder avec ça.
C'est claire que si on considère que ces trucs (limiter le nombre de fork, etc...) marche nickel, n'ont pas d'effet de bord, etc, il est claire que quand je dis que c'est de la connerie, je passe pour un abruti profond.
Mais ces systèmes ont des effets de bord. Voir Windows qui a tout un tas de truc dans ce goût. Mais comme ils ont des effets de bords, Windows donne à l'utilisateur la possibilité de les désactiver. Et c'est ce que fait la majorité des utilisateurs, ce qui donc enlève l'intérêt de ces "trucs".
> Je serais plutôt tenté de dire que c'est à l'utilisateur aguerri qui aurait besoin de mettre des valeurs illimitées
Il faut peser le pour et le contre. Mettre des limites est contraignant (par définition). Si c'est seulement pour eviter qu'un utilisateur chez lui reboote ça bécane 1 fois tous les 3 ans car un programme a déconné, je trouve que c'est trop d'inconvénient et il y a aussi le risque que finalement l'utilisateur désactive tout ce qui le limite.
Si c'est sur un serveur qui héberge une centaine de site web professionnel avec des informations confidentiel, etc, c'est claire que même un reboote imprévu n'est pas tolérable même si c'est tout les trois ans et que l'utilisation de ulimit doit être vivement encouragée.
> protègerait 99% des autres.
Protéger de quoi ?
D'un reboot tout les trois ans ?
Un programme mal intentionné n'a pas besoin de se fock 1000 fois pour faire des dégâts.
> Sinon on peut dire également que les distribs linux pourraient laisser le port telnet d'ouvert
Tu parles de donner la possibilité à des personnes externes d'utiliser ta bécane, ça n'a rien à voir. On parle d'utilisateur légitime qui lance un programme.