Ce n'est pas la seule raison.
La raison principale selon moi, est qu'il y a une communauté de développeur nombreuse (toute chose étant égale par ailleurs), douée et avec une solide réputation de sérieux.
L'autre raison est que ext4 n'est pas une écriture complete d'un FS, mais une évolution (majeur) d'un FS existant.
Ext4 a aussi un roadmap assez précis.
Tu l'as dit, c'est un abruti. Fout lui un coup pied au cul bien senti.
De plus, s'il est dans la salle d'info avec de mauvaises intentions, il n'a pas besoin de faire un fork bomb pour foutre le bordel. Il débranche une prise de courrant, une prise réseau, une prise clavier, pique 1 seconde la souris pour cliquer sur "fermeture" ou fait <alt><F4>, etc...
Le truc le plus "marrant" c'est lorsqu'un utilisateur n'a plus les yeux sur ça session (il discute, il est allé pisser, etc), c'est de changer son mot de passe. Même les connards y pensent.
> on est dans un contexte desktop, et pourtant.
Pas vraiment puisqu'il peut y avoir plusieurs utilisateurs (de plus simultanément) sur une même bécane. La bécane devient un serveur de session.
Enfin, les salle informatiques sont des lieux où on fédère. En un sens ça doit quasiment être considéré comme des serveurs. Or pour les serveurs je n'ai jamais dit qu'ulimit était inutile.
> Autre situation : t'es connecte a distance sur la machine et un connard la reboot.
C'est un connard. Tu peux interdire la commande reboot, même si c'est un connard, il va penser à débrancher la prise ou appuis sur le bouton reset. Même un connard profond peut penser ça et ulimit est en rien une solution à ce problème.
> Ben ouais, mais on est vendredi, 17h38, l'admin vient de partir en we, t'attendra lundi mon coco... Vecu par moi meme, et plusieurs fois.
Et oui, la vie est dure. Mais ulimit ne change rien dans ce que tu as dit et t'en es la preuve puisque tu utilises ulimit (si tu l'utilises, ce que maintenant j'en doute).
> Non. T'avais qu'a mettre un ulimit
La solution magique mais que ces abrutis de distributeur avec tous leurs experts ne mettent pas en oeuvre.
Oui, oui, oui, oui. C'est celà.
> DoS, encore une fois.
Pour info, en passant.
Si tu configure ulimit pour qu'il soit efficace il faut le configure à 100 voir 150 processus grand maximum. Un utilisateur peut légitiment atteindre cette limite. Dans ce cas c'est aussi un denial of service. Oui oui et avec presque les même conséquences.
Certe, ce n'est pas un denial of service attack. Mais pour l'utilisateur c'est un denial of service.
> on va pas embaucher un mec pour nous expliquer qu'il peut pas faire ce qu'il est cense faire.
C'est clair que toi vu le niveau élevé de tes analyses (même pas foutu d'imaginer ce que peut faire un connard), je ne risque pas de t'embaucher.
> Qu'est ce que tu gagnes a utiliser ulimit? la garantie qu'un fork bomb ne marchera pas.
> Qu'est ce que tu perds a utiliser ulimit? rien.
J'ai répondu à ça plus haut.
> mais j'ai l'impression que ce que t'as pas compris, c'est que, justement, le boulot de l'admin, ben c'est que ce genre de choses ca arrive pas.
Et ça t'est arrivé combien de fois sur des postes desktop ?
0 ou 1 fois ?
Et les conséquences ? Un reboot. Mais tu as vu combien de reboot "sauvage" (non désiré), de reset à cause d'un nouveau noyau qui a un driver qui sucks, ou à cause d'un problème hardware (une carte mal insérée, etc) ou de coupure de courant ? 1000 et peut-être probablement plus.
Si tu es préoccupé par les reboots "sauvage", je te comprend. Mais il y bien autres chose a faire avant de regarder du côté d'ulimit. Et tu configures ulimit pour que les fork bomb soient anodins, tu seras emmerdé par quelques utilisateurs qui font une utilisation un poil poussé de linux. Ils vont perdre du temps, tu vas perdre du temps pour finalement virer ou du moins atténué ulimit (ce qui probablement ne te mettra plus à l'apris d'un fork bomb). Et ça pour quoi ? Pour éviter au mieux 0,1 % des reboots "sauvages". Et 0,1 %, je suis gentil, ça doit être beaucoup moins.
Si on te paye pour ça, si on te paye pour être préoccupé par ça au lieu de t'investir dans d'autres domaines qui impactent significativement le fonctionnement de l'entreprise, alors t'es dans une boite blindée de tune et pas soucieuse du rendement, de la plus-value, de ses employés. Un conseil : restes y.
Rappel : on parle d'un usage desktop et non serveur.
Si tu veux éviter les fork bomb de façon significative, il faut que tu limites à 50 ou 100 processus (voirs 150). Au dessus, un fork bomb qui lance des processus qui bouffent du cpu te rend la bécane quasi inutilisable => donc reboot.
Hors 50 ou 100 processus pour un utilisateur ce n'est pas exceptionnel. Donc ce qu'on perd en utilisant ulimit pour limité le nombre de processus (et en le configurant pour qu'il soit utile et non qu'il donne seulement une impression de sécurité) c'est la possibilité d'utiliser sa bécane de façon un poil poussé (pas la peine de faire des choses extraordinaires).
Et tout ça pour quoi ? Pour éviter un reboot tous les 36 du mois. Je trouve qu'il est 1000 plus pertinant d'installer des ondulateurs. Il y a 1000 fois plus de reboot car l'alimentation tombe en panne qu'à cause d'un fork bomb. Je me trompe ? Je ne crois pas.
Question : Il est à combien ton ulimit ?
À moins de 100 ? J'en doute.
> Limiter le fork je vois pas qui ça peut emmerder dans le commun des mortels au sens large
Si tu ne limites pas de façon significative, par exemple si tu autorises 1000 processus ou même "seulement" 250, c'est largement assez pour rendre la bécane inutilisable (tu lances 1000 processus qui bouffent du cpu, c'est à la porté du commun des informaticiens).
Si ça ne gêne pas, ou du moins si ce n'est pas potentiellement génant, c'est sans intérêt.
> Limiter le fork je vois pas qui ça peut emmerder
Ici (fc6), par défaut c'est "limité" (notes bien les guillements) à 8191 ! Autant dire qu'il n'y a pas de limite et on a le "problème" décrit ci-dessus.
Si c'est un processus malintentionné et qu'il peut faire seulement un fork (inutile d'avoir 8191 ou "seulement" 250 de disponible), il a largement de quoi faire des dégâts (par exemple il peut faire un exec("rm -r -f /")).
Désolé, j'avais mal compris. J'étais dans le cas de l'utilisation d'ulimit pour limité l'utilisation de la mémoire.
> Toute la table de processus est prise par tes fork bomb , et si tu arrive trop tard (cad 3 sec apres le lancement) tu ne pourras strictement plus rien faire. Meme pas lancé un kill, car le temps qu'une place se libere dans la table des processus , il sera repris par un autre fils.
Certe, il faut rebooter. La grande affaire. Oui, c'est une grande affaire pour un serveur. Mais pour un serveur je n'ai jamais dit que ulimit n'avait pas de sens, bien au contraire.
> Le plus drole c'est que c'est toi qui prone l'interdiction pur et dur de compilation/execution de binaire non approuvé par l'administration ,
J'ai dit ça pour le cas d'une bécane qui est adminitrée par un administrateur. On n'est plus dans le cas de monsieur tout le monde qui installe une Ubuntu pour son usage personnel.
Ceci pour des raisons de sécurité et notamment de confidentialité. Dans une entreprise (puisque la bécane est administrée) c'est IMPORTANT ! C'est 8 millions de fois plus important que le reboot d'une bécane (qui de plus n'est pas un serveur) tous les 3 ans car on n'a pas configuré ulimit.
Avec un programme malintentionné que l'utilisateur a lancé par mégarde, depuis l'extérieur tu peux avoir un accès à la bécane qui est dans l'entreprise ! Oui oui !
Ce programme peut aussi s'amuser à envoyer des documents de l'utilisateur (en fait, de l'entreprise) sur internet !
C"est 80 milliard de milliard de fois plus grave qu'un improbable reboote d'une bécane qui n'est pas un serveur.
Et pourtant je ne suis pas si tyranique que ça. Ça dépend des données sur la bécane, des accès réseaux qu'elle a etc... Mais si c'est la secrétaire du boss par exemple, je vais être assez intransigeant.
Ça montre a quel point j'en ai rien à foutre d'ulimit pour un desktop.
Ulimit est vachement bien, même pour un desktop, dans un cas que je connais : pour gpg. Aujourd'hui beaucoup de distributions *autorisent* (et non restraindre ; car par défaut sur Linux on ne peut pas le faire) via pam/ulimit 32 ko de mémoire verrouillable (c'est-à-dire non swappable). C'est utilisé par gpg pour que le mot de passe qui est tapé ne se retrouve pas dans le swap. C'est une excellente idée. Ça devrait aussi être utilisé pas ssh, etc...
> mais la mise en place d'un limits.conf par défaut dans les distribs, ah ca non surtout pas...
Qu'un admin le fasse dans son entreprise, pourquoi pas, c'est rapide. Pour une distribution qui va être utilisé par une personne (c'est-à-dire que ce n'est pas un serveur) je n'en vois pas l'intérêt. Et le seul intérêt jusqu'à maintenant avancé est d'éviter un reboot. Ça n'empêche pas l'exploitation de faille de récurité ni rien, ça permet d'éviter un reboot de plus fort improbable. Ici il y a des gens qui parle d'"expérience" avec un "fork bomb", mais en général le "fork bomb" ils se le sont fait eux même, pour le "fun".
Tu parles d'une grande affaire...
Pour le desktop, il y a bien d'autre domaine a améliorer avant de s'occuper d'ulimit. Par exemple OOo. Dans un document OOo on peut mettre des macro qui écrivent sur le disque, etc...
On pourrait, par exemple, dans le cas où le document est ouvert depuis un navigateur ou un client mail (donc en général quand le document vient d'internet), qui lance OOo, avoir une option du type "sandbox" où toutes les lectures/écriture du document y seront faites.
Ça c'est un plus en sécurité et je serait ravis que toutes les distributions l'implémente. De plus ça ne limite pas l'utilisateur. Il peut ouvrir les documents, même ceux compliqué qui nécessite l'écrite sur un périphérique de stockage.
Un autre domaine d'amélioration dans le desktop, est la "généralisation" de la crypto pour les clées USB qu'on ballade partout. Ça implique que toutes les distributions se mettent d'accord sur un standard trivial à utiliser.
Ça aussi c'est un vrai plus. Si t'oublies ta clée chez un pote ou dans un lieu public, et qu'il y avait des documents importants dessus, ça peut faire une différence énorme et qui n'a rien à voir avec un reboot.
> ca dois être vachement simple de developper sur des machines administrées par toi :D
Oui et notamment car je suis aussi développeur donc je comprend les besoins/attendes des développeurs. Mais que le developpeur ne me demande pas le mot de passe root si la bécane est utilisée par plusieurs personnes. Dans ce cas c'est systématiquement un non ferme et définitif. Les sudo sont accordés au compte goutte.
Si le développeur est tout seul sur la bécane, il fait ce qu'il veut et je m'en fout royalement (du moins en tant qu'administrateur). C'est ses affaires.
Mieux, si une développeur est seul sur une bécane et qu'il me demande plus de contrôle alors que j'administre cette bécane, je fais un backup complet et je lui accorde le compte root sans le moindre soucis après avoir viré tous les autres comptes (question de confidentialité). Mais après il se demmerde, je ne veux plus entendre parler de cette bécane. Lorsqu'il a terminé, je restaure mon backup.
NB : C'est vrai que les développeurs se débrouillent bien avec les OS et ont peu besoin d'"assistance". Par contre il faut un peu les responsabiliser. Le développement n'est pas un jeu.
On est en pleine parano. Les spécialistes sécurités estiment que ulimit est sans intérêt sauf pour les serveurs (partage des ressources notamment comme c'est fait avec les quotas). D'où les distributions qui n'ont pas ulimit configuré par défaut ou alors avec des marges telles qu'on peut se demander si on utilise ulimit. C'est trois rien à faire de configurer ulimit, ça existe depuis des lustres, mais les distributions ne le configure pas, les spécialistes sécurités des distributions ne voit pas l'intérêt de son utilisation par défaut. Ulimit n'a jamais empêché d'utiliser une faille de sécurité.
Mais les gens veulent du ulimit. Qu'on leur en donne.
L'effet placébo marche, j'en ai la preuve.
> Sous freebsd, en faisant le fork bomb, le "load average" est quand même monté à plus de 140 ! :)
À 140 d'upload la bécane est inutilisation. Si je suis malintentionné, je peux faire un truc qui fait monter ton upload à 140 et que ton "fork bomb detector" laissera en paix.
Si c'est 140 alors d'un fork bomb c'est rapide, on peut estique que freebsd me permet au moins de lancer 200 processus. L'argement de quoi rendre l'OS inutilisable. Si ça détecte la vitesse des forcks, je peux au moins faire un fork par second en toute discretion. La seule différence, c'est qu'il me faudra 200 seconde (un peu plus de 3 minutes) pour rendre ta bécane inutilisable.
J'espère que tu te sens plus en "sécurité" maintenant avec ton "fork bomb detector".
> ben oui, les voitures récentes polluent moins que les vieilles
Ce n'est pas ça qui fait qu'il est maintenant peu interessant de garder longtemps une voiture (car produire une voiture pollue beaucoup). C'est surtout qu'aujourd'hui les voitures sont beaucoup beaucoup plus recyclées qu'avant (une directive européenne assez "dure" quand on compare avec les autres pays). Tous les plastiques des voitures sont depuis plusieures années repérés dès la fabrication de la voiture en fonction des matériaux utilisés. Ceci facile énormément la récupération des plastiques. Les constructeurs ont obligations de recycler les voitures.
Pour la petite histoire, ça avait scandalisé Chrysler qui avait dit que dans ces conditions ils allaient arrêter la vente de voiture pour ne faire que de la location.
C'est aussi cette directive qui a "inspiré" la Smart (à l'origine c'est une voiture uniquement destinée à la location).
> un programme qui consomme plus de mémoire que le systeme supporte se fait oom killed sans la moindre once de pitié
S'il n'y a pas oom, c'est pire. Lors qu'on arrive à la limite hardware, deux solutions :
- un malloc/mmap/etc echoue et le programme s'arrête "gentillement"
- le programme est killer -9
> ce qui n'existe pas pour les processus
Avec ulimit, c'est presque la même chose :
- un malloc/etc echoue et le programme s'arrête "gentillement"
- le programme est killer -9 si par exemple s'il fait des appels récursives de fonction (la pile augmente).
> Est ce que c'est une raison pour autoriser n'importer quoi alors qu'on a des moyens simples de detecter un probleme evident (j'aimerais bien savoir quelle application a besoin de 16000 forks...)
Si ça arrive, t'as vite fait de t'en rendre compte et ce n'est pas ulimit qui va empêcher l'exploitation de faille de sécurité donc les conséquences n'ont rien à voir avec un petit reboot.
Occupons nous de l'accessoire, le principal attendra...
Si t'es un admin, combien de fois tu as vu une "fork bomb" ?
Probablement jamais.
> je me fiche que ce soit une fork bidou ou je ne sais quoi, je veux mon boulot"
Si t'es un admin, tu interdis l'excécution de programme qui sont dans des répertoires où l'utilisateur peut écrire (donc l'installer). Ainsi l'utilisateur ne peut utiliser que des programmes "approuvé" par l'admin. Et si l'admin fait bien son boulot, il ne met pas de programmes avec des "fork bomb", il ne met que des programme de confiance.
> Que ce soit un bug dans un programme ou autre chose, c'est pas le problème, je vois vraiment pas en quoi ça regarde l'utilisateur si il y a une solution simple et qui ne le fait jamais chier en pratique, genre un ulimit.
Solution qui n'empêche pas l'utilisateur d'installer un programme qui fait une bête "rm -r -f $HOME" ou d'envoyer tous ses documents confidentiel sur le web.
Tu parles d'une politique de sécurité...
J'ai d'autres priorités.
Ne me dit pas que tu es administrateur s'il te plait.
> 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.
Où est la politique de sécurité quand on est dans l'hypothèse de personnes qui lancent tout et n'importe quoi comme programme ?
Et c'est une politique de sécurité de détecter les "fork bomb" ?
Le gus qui download tout et n'importe peut aussi downloader des programmes qui supprimer des fichiers. Et là les inconvénient non rien à voir un reboote car un fork bomb fait swapper la bécane comme une dingue.
Mais dors tranquille, t'as un truc pour détecter les "fork bomb". Bonne nuit.
> Apparemment, le second degré de mon commentaire précédent n'était pas assez apparent.
Désolé.
> Pour moi, limiter le nombre de processus par défaut est au même titre que l'utilisation de la mémoire protégée, ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur/des performances brutes mais permettant une sécurité, une stabilité et un confort d'utilisation compensant plus que largement son coût.
Non. Limiter le nombre de processus n'est pas la même chose que la mémoire protégée. Ce n'est pas parceque tu as de la mémoire protégée que tu ne peut pas faire un "malloc(4Go)" qui fait swapper ta bécane comme un fou voire aboutis à des "kill ... Out of memory" par le noyau.
La mémoire protégée c'est pour avoir plusieurs processus à la fois, ça ne limite pas l'utilisateur dans ce qu'il peut faire.
Par contre ulimit, comme son nom l'indique, limit l'utilisateur dans ce qu'il peut faire.
> ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur
Je ne te suis absolument pas.
En quoi du multitâche préemtif est une mesure restrictive ?
En quoi ça limite la liberté de l'utilisateur ?
Franchement, je ne vois pas du tout.
Si tu veux bouffer 100% du cpu et laisser 0% au autre, tu peux utiliser chrt (faut être root, sinon tu peux aussi faire un "chmod +s" ; c'est vivement déconseillé).
Le multitache préemtif n'est pas pour limiter les utilisateurs, c'est là encore le contraire. C'est pour permettre à plusieurs personne/programme de bosser en même temps. Au-lui qu'un programme attende la fin du programme en cours, il a la liberté de s'exécuter tout de suite.
Si tu as windows 3.1, il ne peut y avoir qu'une personne/programme à la fois. Si tu as un système multitache, t'as plus de liberté et non moins. Si plusieurs personnent utilisent le même PC en même temps, les ressources du PC sont plus utilisées et non moins utilisées.
Bref, je ne te comprend absolument pas.
> Laisser le nombre de processus illimité est un DoS potentiel, et il n'y aucune raison valable de ne pas combler cette faille.
Mais là tu parles d'un serveur. Un programme qui n'est pas accessible de l'extérieur ne peut pas être attaqué.
Au début du thread il y avait :
- "En gros, OUI au contrôle du fork sous ubuntu/mandriva/suse..."
C'est un dire pour des distributions qui ne sont pas orientées serveurs mais orientées desktop (ça ce discute).
Puis je le répète pour la millième fois : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK".
> Je suis sous Slack et je limite *volontairement* le nombre de processus pour mon compte utilisateur.
TU te limites comme bon te semble, j'en ai rien à foutre. Mais si c'est un autre qui le fait pour toi ? Ça te plait ?
Si un jour le programme bidule ne se lance pas car il utiliser 201 thread et qu'un autre a limité le nombre de thread par process à 200 pour soit disant ton bien, t'es content ?
> Y a des gens qui ont le même dédain que toi pour la limitation du nombre de processus
Je n'ai aucun dédain pour ulimit, etc. C'est un truc indispensable pour un serveur. Mais limiter ce que fait l'utilisateur avec le prétexte que c'est pour son bien alors qu'on est dans un contexte desktop est de la connerie. S'il a 4 Go de mémoire et veut tout utiliser, c'est ses oignons, je ne vois pas pourquoi on va le limiter, et si ça fait ramer sa bécane au point de la rendre inutilisable, ça n'emmerde que lui. Je suis persuadé qu'il ne recommencera pas et que pour ce type de problème il est ridicule, pour ne pas dire néfaste, de développer une solution.
> En effet, même si on est un brave utilisateur qui ne lance jamais de programme malveillant, on n'est jamais à l'abri d'un programme tout à fait légitime, codé par des gens respectable, mais qui comporte un bug vicieux.
Si tu crois qu'un jour ou pourra éviter les effets de bord des programmes codés avec le pied, tu te trompes lourdement.
> Si ça arrive, chez moi le programme se fera tuer froidement par le noyau, mais toi tu rebooteras ta machine.
Oui, et je ne relance plus ce programme. Si ma bécane sert aussi de serveur, alors j'utilise ulimit. S'il n'y a que moi, alors je n'utilise pas ulimit.
Puis là encore on est dans du hors sujet. Limite toi tant que tu veux, je m'en fous. Mais qu'on te limite, tu serais d'accord ?
> Et si ton programme avait une faille, et qu'un attaquant l'a exploitée pour te lancer une fork bomb ?
Dans ce cas, c'est un programme qui fait serveur ou qui est accessible depuis l'extérieur (par exemple bittorrent). Le comportement du programme ne dépend pas que de l'utilisateur. Dans ce cas, le programme peut (et souvent le fait) de lui même faire les appels systèmes qui vont bien pour que l'OS lui fournisse que ce dont il a besoin et pas plus. On voit ça avec les serveurs qui sont lancé en root, puis utilise capability, puis passe sous un compte non privilégié. C'est le programme, qui connait ce dont il a besoin, qui le fait. Ce n'est pas un programme tière qui le fait soit disant pour le bien de l'utilisateur.
Notes bien, que tout ce qui précède, ne limite pas l'utilisateur !
De plus, j'ai dit : "Qu'un OS se protège des attaques extérieures, OK, mille fois OK". C'est aussi valable pour les programmes pour qu'il se protège, celà va de soit.
> Comment t'aperçois-tu que c'était lui qui a été attaqué? (Si tu es non-informaticien)
"lui" ? qui "lui" ?
Le programme que tu viens de downloader ?
Un programme de la distribution ?
Si le programme vient de la distribution, il y aura une mise à jour, etc...
Si c'est un programme que tu as downloadé d'une source qui n'est pas de confiance, ben t'as pris des risques et c'est à toi de te demmerder.
Exécutes cette commande : "rm -r -f /"
Tu l'as fait ?
Si tu l'as fait, ton programme pour veiller à ta sécurité a marché ?
Si tu ne l'as pas fait, alors pourquoi ?
> (Si tu es non-informaticien)
Je suis informaticien. Ben si j'ai un programme qui supprimer des fichiers dans mon dos, ... ben je ne suis pas au courant non plus (ou du moins bien trop tard). Ce qui est dissimulé est par définition dissimulé. Une attaque fork bomb ne vas pas dire : "coucou, je vais faire une attaque".
Suivons ta logique, on met un truc pour détecter les fork bombs. Mais l'utilisateur après avoir downloadé un programme qui fait des fork bomb, peut aussi downloadé un programme qui supprime des fichiers du disque dur. Mieux, au-lui de downloader les programmes, il peuvent d'exécuter dans le navigateur comme les ActiveX de MS (puisqu'on a des trucs qui contrôle tout, on ne va pas se priver).
On fait quoi ?
On suit ta logique et on ajoute un truc qui détecte les suppressions de fichier et qui 9/10 les détecte trop tard....
Pire, considérons que tous ces trucs de surveillance marchent (c'est une supposition). Ben il y aura plein de programmes à la con d'installés et de développés car les gens se disent qu'il y aura le contrôle "big brother" qui va ratrapper la situation.
Bref, c'est le modèle Windows/antivirus qui suxe grave. Pourtant les anti-virus sont tout plein de bonne intention, les efforts marketing pour nous le faire croire sont remarquables. Windows aussi est tout plein de bonnes intention et n'arrête pas de nous le répéter (comme ton truc de détection de "fork bomb" est tout plein de bonne intention). Linux c'est tout le contraire. Avec Windows, ses assistants sécurité, etc ... et on est dans un monde meilleur avec plein de programmes plein de bonnes intentions et qui veillent sur nous pauvre abrutis d'utilisateur (dormez tranquille on veille sur vous). Mais dans la pratique ce modèle suxe grave de chez grave. Le comparatif Windows/Linux|Unix nous en fait la démonstration tous les jours.
Les problèmes de sécurité c'est compriqué et il faut toujours y réfléchir sur plusieurs niveaux. Par exemple un truc qui détecte si l'ActiveX bidule dans la page qu'affiche IE supprime un fichier ou fait un "fork bomb", c'est bien. Mais pas d'ActiveX dans les page web c'est beaucoup mieux. C'est exactement ce que fait FireFox (pas d'ActiveX). Il n'y a pas un truc au-dessus de Firefox pour le limiter et ce pour le bien de l'utilisateur. Firefox se limite de lui même. Si tu as confiance en Firefox (et je pense que tu devrais) alors utilise le et pleinement. Si tu n'as pas confiance en IE (et je pense que tu ne devrais pas) alors n'utilise pas IE. Qu'il y est ou non un "big brother" qui contrôle ce que fait IE ne change rien.
T'as jamais pensé qu'il faudrait un système pour contrôler ce qui contrôle ce que fait l'utilisateur ?
> y'a 3 millions de foyers qui sont prêts à faire un effort pour la planète...
De ces 3 millions, combien roulent en 4x4 climatisé avec un autocollant Ushuaïa sur la lunette arrière pour aller à la boulangerie du coin ?
De ces 3 millions, combien utilise des ampoules basse énergie ? Pas beaucoup.
De ces 3 millions, combien on ce jours là éteind... une lampe allogène de 300 W ?
Ou combien laisse tourner leur PC tourner toute la nuit car ils downloadent avec bittorrent ?
Combien ont plusieurs télés dans la maison qui tournent en même temps ?
Combien ont un écran de vieille qui affiche des poisons ou autre niaiserie au lieu de configurer leur OS pour qu'il éteigne l'écran ?
Et combien prennent une douche par jour avec de l'eau chaude ? Ça pompe de l'énergie ça (en plus de l'eau). Et pas qu'un peu. Beaucoup plus que d'éteindre une heure la lumière. Lumière qui pourrait être utilisé à lire un livre, permettre au gamin de faire ses dévoirs, faire la cuisine avec des produits bio, etc. Bref, la lumière c'est vraiment utile et je pense que les écolos devraient s'attaquer à autre chose que ça.
> Tu ne t'es jamais dit que tout le monde n'est pas informaticien???
Mon dieu. J'ai dit que l'utilisateur doit apprendre à ne pas lancer un programme s'il c'est apperçu que ce programme écroule sa bécane. En fait, il n'y a rien à apprendre, les gens font ça d'instinct.
Toi tu prends les utilisateurs pour des cons, très très cons.
Ce n'est pas mon cas.
Pour finir, je n'ai jamais dit que j'étais contre les interfaces graphiques simples ou des outils d'administration simples.
Donc je ne vois pas où tu veux en venir.
> Ben je te l'annonce alors:
> Tout le monde n'est pas informaticien!
Ben je te l'annonce alors: Les non informaticiens ne sont pas des cons !
> Ouais, halte à la tyrannie de l'OS qui nous prive de nos ressources, abolissons la mémoire protégée et abattons le scheduler, je veux pouvoir bouffer tout le processeur quand ça me chante et écrire où je veux en mémoire !
Tu n'as pas compris ce que je dis ou je me suis mal exprimé.
> halte à la tyrannie de l'OS qui nous prive de nos ressources
C'est faux, c'est lui qui nous permet d'accéder aux ressources.
> abolissons la mémoire protégée
Jamais dit ça. La mémoire protégée permet d'avoir plusieur processus en même temps et c'est un moyen pour protégé l'OS (j'ai dit : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK")
> abattons le scheduler
Jamais dit une telle absurditée. Le scheduler permet d'utiliser les ressources dans un contexte multiprocessus. Utilises Windows 3.1 et tu vas vite comprendre.
Le scheduler n'est pas un truc pour limiter l'utilisation des ressources, c'est l'inverse.
> je veux pouvoir bouffer tout le processeur quand ça me chante
Pareil pour moi.
> et écrire où je veux en mémoire !
Je veux écrire en mémoire. Mais le lieu m'importe peu.
Bof. M'enfin tu peux toujours avec le compte root et /dev/mem.
> C'est pas par ce que JE sais conduire que je demande à ce qu'on enlève les parapets des ponts, pour moi et pour les autres !!!
Tu mélanges un peu tout.
> Sinon, on met qu'un compte admin en arguant que MOI je sais ce que je fais sur MA distrib.
Tu peux parfaitement toujours utiliser le compte root. Le fais-tu ?
J'espère que non. Et si tu n'utilises pas le compte root, c'est TA décision.
S'il y a une distribution qui m'interdit l'accès au compte root pour soit disant ma sécurité, alors je la fous aux orties.
> En gros, OUI au contrôle du fork sous ubuntu/mandriva/suse...
NON et NON !
Pourquoi il y aurait des fork sauvages sur TA bécane ?
Car TU as downloadé des programmes à la con que TU exécutes intentionnellement dans TON environnement utilisateur. Si un utilisateur est con au point de downloader et tester tout et n'importe, on aura beau faire, ça sera toujours le bordel.
De même, j'espère que tu n'installes pas tous les noyaux que tu trouves sur le web.
TON environnement utilisateur autorise 8000 process, ça écroule (et non plante, car ça ne doit pas faire planter l'OS) TA bécane. Et lors ? Ne relances pas, TOI, le programme qui fait écrouler TA bécane. C'est si compliqué ?
Qu'un OS se protège des attaques extérieures, OK, mille fois OK.
Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK.
Qu'un OS protège de la bêtise d'un utilisateur, alors NON et mille fois NON.
D'ailleur j'aime bien faire des conneries de temps en temps avec ma bécane.
L'OS met à disposition des ressources à un utilisateur (cpu, mémoire, etc). L'objectif d'un OS, n'est pas empêcher l'utilisation de ces ressources. C'est justement le contraire. Si l'utilisateur veut, de son propre chef, lancer un programme qui fait 16 000 fork, c'est ses oignons. Si la bécane le supporte et que l'utilisateur est content, tant mieux. Si la bécane ne le supporte pas, ben l'utilisateur ne relance plus ce programme. Fin de l'histoire.
> a moins de statuer sur un probleme de concurrence faussee...
Et dans ce domaine l'Europe ne s'occupe que de la concurrence faussée entre pays européens. Si la concurrence est faussée mais seulement au sein d'un pays, ça ne regarde pas les institutions européennes.
Ça permet à des pays de mettre en place des monopoles ou les conserver. Du moins tant que ceux-ci ne sont pas utilisés pour pénétrer les marchés d'autres pays (voir EDF qui était un monopole mais, puisque EDF vend de l'électricité à l'étranger, ne peut plus être un monopole).
Notons que l'avis de la commission européenne n'empêche pas l'administration française de prévilégier le libre. Dans ce cas l'administration est un client de produit informatique comme un autre qui choisi parmis les produits disponibles.
[^] # Re: Ubuntu / Debian, une question de philosophie
Posté par IsNotGood . En réponse au journal CQFD. Évalué à -6.
Le sujet debian est populaire. La distribution non.
[^] # Re: Ubuntu / Debian, une question de philosophie
Posté par IsNotGood . En réponse au journal CQFD. Évalué à -10.
[^] # Re: ext4
Posté par IsNotGood . En réponse à la dépêche Sortie de Linux 2.6.20. Évalué à 3.
La raison principale selon moi, est qu'il y a une communauté de développeur nombreuse (toute chose étant égale par ailleurs), douée et avec une solide réputation de sérieux.
L'autre raison est que ext4 n'est pas une écriture complete d'un FS, mais une évolution (majeur) d'un FS existant.
Ext4 a aussi un roadmap assez précis.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
Tu l'as dit, c'est un abruti. Fout lui un coup pied au cul bien senti.
De plus, s'il est dans la salle d'info avec de mauvaises intentions, il n'a pas besoin de faire un fork bomb pour foutre le bordel. Il débranche une prise de courrant, une prise réseau, une prise clavier, pique 1 seconde la souris pour cliquer sur "fermeture" ou fait <alt><F4>, etc...
Le truc le plus "marrant" c'est lorsqu'un utilisateur n'a plus les yeux sur ça session (il discute, il est allé pisser, etc), c'est de changer son mot de passe. Même les connards y pensent.
> on est dans un contexte desktop, et pourtant.
Pas vraiment puisqu'il peut y avoir plusieurs utilisateurs (de plus simultanément) sur une même bécane. La bécane devient un serveur de session.
Enfin, les salle informatiques sont des lieux où on fédère. En un sens ça doit quasiment être considéré comme des serveurs. Or pour les serveurs je n'ai jamais dit qu'ulimit était inutile.
> Autre situation : t'es connecte a distance sur la machine et un connard la reboot.
C'est un connard. Tu peux interdire la commande reboot, même si c'est un connard, il va penser à débrancher la prise ou appuis sur le bouton reset. Même un connard profond peut penser ça et ulimit est en rien une solution à ce problème.
> Ben ouais, mais on est vendredi, 17h38, l'admin vient de partir en we, t'attendra lundi mon coco... Vecu par moi meme, et plusieurs fois.
Et oui, la vie est dure. Mais ulimit ne change rien dans ce que tu as dit et t'en es la preuve puisque tu utilises ulimit (si tu l'utilises, ce que maintenant j'en doute).
> Non. T'avais qu'a mettre un ulimit
La solution magique mais que ces abrutis de distributeur avec tous leurs experts ne mettent pas en oeuvre.
Oui, oui, oui, oui. C'est celà.
> DoS, encore une fois.
Pour info, en passant.
Si tu configure ulimit pour qu'il soit efficace il faut le configure à 100 voir 150 processus grand maximum. Un utilisateur peut légitiment atteindre cette limite. Dans ce cas c'est aussi un denial of service. Oui oui et avec presque les même conséquences.
Certe, ce n'est pas un denial of service attack. Mais pour l'utilisateur c'est un denial of service.
> on va pas embaucher un mec pour nous expliquer qu'il peut pas faire ce qu'il est cense faire.
C'est clair que toi vu le niveau élevé de tes analyses (même pas foutu d'imaginer ce que peut faire un connard), je ne risque pas de t'embaucher.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 4.
> Qu'est ce que tu perds a utiliser ulimit? rien.
J'ai répondu à ça plus haut.
> mais j'ai l'impression que ce que t'as pas compris, c'est que, justement, le boulot de l'admin, ben c'est que ce genre de choses ca arrive pas.
Et ça t'est arrivé combien de fois sur des postes desktop ?
0 ou 1 fois ?
Et les conséquences ? Un reboot. Mais tu as vu combien de reboot "sauvage" (non désiré), de reset à cause d'un nouveau noyau qui a un driver qui sucks, ou à cause d'un problème hardware (une carte mal insérée, etc) ou de coupure de courant ? 1000 et peut-être probablement plus.
Si tu es préoccupé par les reboots "sauvage", je te comprend. Mais il y bien autres chose a faire avant de regarder du côté d'ulimit. Et tu configures ulimit pour que les fork bomb soient anodins, tu seras emmerdé par quelques utilisateurs qui font une utilisation un poil poussé de linux. Ils vont perdre du temps, tu vas perdre du temps pour finalement virer ou du moins atténué ulimit (ce qui probablement ne te mettra plus à l'apris d'un fork bomb). Et ça pour quoi ? Pour éviter au mieux 0,1 % des reboots "sauvages". Et 0,1 %, je suis gentil, ça doit être beaucoup moins.
Si on te paye pour ça, si on te paye pour être préoccupé par ça au lieu de t'investir dans d'autres domaines qui impactent significativement le fonctionnement de l'entreprise, alors t'es dans une boite blindée de tune et pas soucieuse du rendement, de la plus-value, de ses employés. Un conseil : restes y.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 3.
Rappel : on parle d'un usage desktop et non serveur.
Si tu veux éviter les fork bomb de façon significative, il faut que tu limites à 50 ou 100 processus (voirs 150). Au dessus, un fork bomb qui lance des processus qui bouffent du cpu te rend la bécane quasi inutilisable => donc reboot.
Hors 50 ou 100 processus pour un utilisateur ce n'est pas exceptionnel. Donc ce qu'on perd en utilisant ulimit pour limité le nombre de processus (et en le configurant pour qu'il soit utile et non qu'il donne seulement une impression de sécurité) c'est la possibilité d'utiliser sa bécane de façon un poil poussé (pas la peine de faire des choses extraordinaires).
Et tout ça pour quoi ? Pour éviter un reboot tous les 36 du mois. Je trouve qu'il est 1000 plus pertinant d'installer des ondulateurs. Il y a 1000 fois plus de reboot car l'alimentation tombe en panne qu'à cause d'un fork bomb. Je me trompe ? Je ne crois pas.
Question : Il est à combien ton ulimit ?
À moins de 100 ? J'en doute.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
Si tu ne limites pas de façon significative, par exemple si tu autorises 1000 processus ou même "seulement" 250, c'est largement assez pour rendre la bécane inutilisable (tu lances 1000 processus qui bouffent du cpu, c'est à la porté du commun des informaticiens).
Si ça ne gêne pas, ou du moins si ce n'est pas potentiellement génant, c'est sans intérêt.
> Limiter le fork je vois pas qui ça peut emmerder
Ici (fc6), par défaut c'est "limité" (notes bien les guillements) à 8191 ! Autant dire qu'il n'y a pas de limite et on a le "problème" décrit ci-dessus.
Si c'est un processus malintentionné et qu'il peut faire seulement un fork (inutile d'avoir 8191 ou "seulement" 250 de disponible), il a largement de quoi faire des dégâts (par exemple il peut faire un exec("rm -r -f /")).
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
Désolé, j'avais mal compris. J'étais dans le cas de l'utilisation d'ulimit pour limité l'utilisation de la mémoire.
> Toute la table de processus est prise par tes fork bomb , et si tu arrive trop tard (cad 3 sec apres le lancement) tu ne pourras strictement plus rien faire. Meme pas lancé un kill, car le temps qu'une place se libere dans la table des processus , il sera repris par un autre fils.
Certe, il faut rebooter. La grande affaire. Oui, c'est une grande affaire pour un serveur. Mais pour un serveur je n'ai jamais dit que ulimit n'avait pas de sens, bien au contraire.
> Le plus drole c'est que c'est toi qui prone l'interdiction pur et dur de compilation/execution de binaire non approuvé par l'administration ,
J'ai dit ça pour le cas d'une bécane qui est adminitrée par un administrateur. On n'est plus dans le cas de monsieur tout le monde qui installe une Ubuntu pour son usage personnel.
Ceci pour des raisons de sécurité et notamment de confidentialité. Dans une entreprise (puisque la bécane est administrée) c'est IMPORTANT ! C'est 8 millions de fois plus important que le reboot d'une bécane (qui de plus n'est pas un serveur) tous les 3 ans car on n'a pas configuré ulimit.
Avec un programme malintentionné que l'utilisateur a lancé par mégarde, depuis l'extérieur tu peux avoir un accès à la bécane qui est dans l'entreprise ! Oui oui !
Ce programme peut aussi s'amuser à envoyer des documents de l'utilisateur (en fait, de l'entreprise) sur internet !
C"est 80 milliard de milliard de fois plus grave qu'un improbable reboote d'une bécane qui n'est pas un serveur.
Et pourtant je ne suis pas si tyranique que ça. Ça dépend des données sur la bécane, des accès réseaux qu'elle a etc... Mais si c'est la secrétaire du boss par exemple, je vais être assez intransigeant.
Ça montre a quel point j'en ai rien à foutre d'ulimit pour un desktop.
Ulimit est vachement bien, même pour un desktop, dans un cas que je connais : pour gpg. Aujourd'hui beaucoup de distributions *autorisent* (et non restraindre ; car par défaut sur Linux on ne peut pas le faire) via pam/ulimit 32 ko de mémoire verrouillable (c'est-à-dire non swappable). C'est utilisé par gpg pour que le mot de passe qui est tapé ne se retrouve pas dans le swap. C'est une excellente idée. Ça devrait aussi être utilisé pas ssh, etc...
> mais la mise en place d'un limits.conf par défaut dans les distribs, ah ca non surtout pas...
Qu'un admin le fasse dans son entreprise, pourquoi pas, c'est rapide. Pour une distribution qui va être utilisé par une personne (c'est-à-dire que ce n'est pas un serveur) je n'en vois pas l'intérêt. Et le seul intérêt jusqu'à maintenant avancé est d'éviter un reboot. Ça n'empêche pas l'exploitation de faille de récurité ni rien, ça permet d'éviter un reboot de plus fort improbable. Ici il y a des gens qui parle d'"expérience" avec un "fork bomb", mais en général le "fork bomb" ils se le sont fait eux même, pour le "fun".
Tu parles d'une grande affaire...
Pour le desktop, il y a bien d'autre domaine a améliorer avant de s'occuper d'ulimit. Par exemple OOo. Dans un document OOo on peut mettre des macro qui écrivent sur le disque, etc...
On pourrait, par exemple, dans le cas où le document est ouvert depuis un navigateur ou un client mail (donc en général quand le document vient d'internet), qui lance OOo, avoir une option du type "sandbox" où toutes les lectures/écriture du document y seront faites.
Ça c'est un plus en sécurité et je serait ravis que toutes les distributions l'implémente. De plus ça ne limite pas l'utilisateur. Il peut ouvrir les documents, même ceux compliqué qui nécessite l'écrite sur un périphérique de stockage.
Un autre domaine d'amélioration dans le desktop, est la "généralisation" de la crypto pour les clées USB qu'on ballade partout. Ça implique que toutes les distributions se mettent d'accord sur un standard trivial à utiliser.
Ça aussi c'est un vrai plus. Si t'oublies ta clée chez un pote ou dans un lieu public, et qu'il y avait des documents importants dessus, ça peut faire une différence énorme et qui n'a rien à voir avec un reboot.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
Oui et notamment car je suis aussi développeur donc je comprend les besoins/attendes des développeurs. Mais que le developpeur ne me demande pas le mot de passe root si la bécane est utilisée par plusieurs personnes. Dans ce cas c'est systématiquement un non ferme et définitif. Les sudo sont accordés au compte goutte.
Si le développeur est tout seul sur la bécane, il fait ce qu'il veut et je m'en fout royalement (du moins en tant qu'administrateur). C'est ses affaires.
Mieux, si une développeur est seul sur une bécane et qu'il me demande plus de contrôle alors que j'administre cette bécane, je fais un backup complet et je lui accorde le compte root sans le moindre soucis après avoir viré tous les autres comptes (question de confidentialité). Mais après il se demmerde, je ne veux plus entendre parler de cette bécane. Lorsqu'il a terminé, je restaure mon backup.
NB : C'est vrai que les développeurs se débrouillent bien avec les OS et ont peu besoin d'"assistance". Par contre il faut un peu les responsabiliser. Le développement n'est pas un jeu.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 3.
On est en pleine parano. Les spécialistes sécurités estiment que ulimit est sans intérêt sauf pour les serveurs (partage des ressources notamment comme c'est fait avec les quotas). D'où les distributions qui n'ont pas ulimit configuré par défaut ou alors avec des marges telles qu'on peut se demander si on utilise ulimit. C'est trois rien à faire de configurer ulimit, ça existe depuis des lustres, mais les distributions ne le configure pas, les spécialistes sécurités des distributions ne voit pas l'intérêt de son utilisation par défaut. Ulimit n'a jamais empêché d'utiliser une faille de sécurité.
Mais les gens veulent du ulimit. Qu'on leur en donne.
L'effet placébo marche, j'en ai la preuve.
> Sous freebsd, en faisant le fork bomb, le "load average" est quand même monté à plus de 140 ! :)
À 140 d'upload la bécane est inutilisation. Si je suis malintentionné, je peux faire un truc qui fait monter ton upload à 140 et que ton "fork bomb detector" laissera en paix.
Si c'est 140 alors d'un fork bomb c'est rapide, on peut estique que freebsd me permet au moins de lancer 200 processus. L'argement de quoi rendre l'OS inutilisable. Si ça détecte la vitesse des forcks, je peux au moins faire un fork par second en toute discretion. La seule différence, c'est qu'il me faudra 200 seconde (un peu plus de 3 minutes) pour rendre ta bécane inutilisable.
J'espère que tu te sens plus en "sécurité" maintenant avec ton "fork bomb detector".
[^] # Re: moi c'est tout les jours
Posté par IsNotGood . En réponse au journal M'enfin ? Et le backout ?. Évalué à 2.
Ce n'est pas ça qui fait qu'il est maintenant peu interessant de garder longtemps une voiture (car produire une voiture pollue beaucoup). C'est surtout qu'aujourd'hui les voitures sont beaucoup beaucoup plus recyclées qu'avant (une directive européenne assez "dure" quand on compare avec les autres pays). Tous les plastiques des voitures sont depuis plusieures années repérés dès la fabrication de la voiture en fonction des matériaux utilisés. Ceci facile énormément la récupération des plastiques. Les constructeurs ont obligations de recycler les voitures.
Pour la petite histoire, ça avait scandalisé Chrysler qui avait dit que dans ces conditions ils allaient arrêter la vente de voiture pour ne faire que de la location.
C'est aussi cette directive qui a "inspiré" la Smart (à l'origine c'est une voiture uniquement destinée à la location).
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
> un programme qui consomme plus de mémoire que le systeme supporte se fait oom killed sans la moindre once de pitié
S'il n'y a pas oom, c'est pire. Lors qu'on arrive à la limite hardware, deux solutions :
- un malloc/mmap/etc echoue et le programme s'arrête "gentillement"
- le programme est killer -9
> ce qui n'existe pas pour les processus
Avec ulimit, c'est presque la même chose :
- un malloc/etc echoue et le programme s'arrête "gentillement"
- le programme est killer -9 si par exemple s'il fait des appels récursives de fonction (la pile augmente).
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
Si ça arrive, t'as vite fait de t'en rendre compte et ce n'est pas ulimit qui va empêcher l'exploitation de faille de sécurité donc les conséquences n'ont rien à voir avec un petit reboot.
Occupons nous de l'accessoire, le principal attendra...
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 1.
Probablement jamais.
> je me fiche que ce soit une fork bidou ou je ne sais quoi, je veux mon boulot"
Si t'es un admin, tu interdis l'excécution de programme qui sont dans des répertoires où l'utilisateur peut écrire (donc l'installer). Ainsi l'utilisateur ne peut utiliser que des programmes "approuvé" par l'admin. Et si l'admin fait bien son boulot, il ne met pas de programmes avec des "fork bomb", il ne met que des programme de confiance.
> Que ce soit un bug dans un programme ou autre chose, c'est pas le problème, je vois vraiment pas en quoi ça regarde l'utilisateur si il y a une solution simple et qui ne le fait jamais chier en pratique, genre un ulimit.
Solution qui n'empêche pas l'utilisateur d'installer un programme qui fait une bête "rm -r -f $HOME" ou d'envoyer tous ses documents confidentiel sur le web.
Tu parles d'une politique de sécurité...
J'ai d'autres priorités.
Ne me dit pas que tu es administrateur s'il te plait.
[^] # 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.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
Où est la politique de sécurité quand on est dans l'hypothèse de personnes qui lancent tout et n'importe quoi comme programme ?
Et c'est une politique de sécurité de détecter les "fork bomb" ?
Le gus qui download tout et n'importe peut aussi downloader des programmes qui supprimer des fichiers. Et là les inconvénient non rien à voir un reboote car un fork bomb fait swapper la bécane comme une dingue.
Mais dors tranquille, t'as un truc pour détecter les "fork bomb". Bonne nuit.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 3.
Désolé.
> Pour moi, limiter le nombre de processus par défaut est au même titre que l'utilisation de la mémoire protégée, ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur/des performances brutes mais permettant une sécurité, une stabilité et un confort d'utilisation compensant plus que largement son coût.
Non. Limiter le nombre de processus n'est pas la même chose que la mémoire protégée. Ce n'est pas parceque tu as de la mémoire protégée que tu ne peut pas faire un "malloc(4Go)" qui fait swapper ta bécane comme un fou voire aboutis à des "kill ... Out of memory" par le noyau.
La mémoire protégée c'est pour avoir plusieurs processus à la fois, ça ne limite pas l'utilisateur dans ce qu'il peut faire.
Par contre ulimit, comme son nom l'indique, limit l'utilisateur dans ce qu'il peut faire.
> ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur
Je ne te suis absolument pas.
En quoi du multitâche préemtif est une mesure restrictive ?
En quoi ça limite la liberté de l'utilisateur ?
Franchement, je ne vois pas du tout.
Si tu veux bouffer 100% du cpu et laisser 0% au autre, tu peux utiliser chrt (faut être root, sinon tu peux aussi faire un "chmod +s" ; c'est vivement déconseillé).
Le multitache préemtif n'est pas pour limiter les utilisateurs, c'est là encore le contraire. C'est pour permettre à plusieurs personne/programme de bosser en même temps. Au-lui qu'un programme attende la fin du programme en cours, il a la liberté de s'exécuter tout de suite.
Si tu as windows 3.1, il ne peut y avoir qu'une personne/programme à la fois. Si tu as un système multitache, t'as plus de liberté et non moins. Si plusieurs personnent utilisent le même PC en même temps, les ressources du PC sont plus utilisées et non moins utilisées.
Bref, je ne te comprend absolument pas.
> Laisser le nombre de processus illimité est un DoS potentiel, et il n'y aucune raison valable de ne pas combler cette faille.
Mais là tu parles d'un serveur. Un programme qui n'est pas accessible de l'extérieur ne peut pas être attaqué.
Au début du thread il y avait :
- "En gros, OUI au contrôle du fork sous ubuntu/mandriva/suse..."
C'est un dire pour des distributions qui ne sont pas orientées serveurs mais orientées desktop (ça ce discute).
Puis je le répète pour la millième fois : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK".
> Je suis sous Slack et je limite *volontairement* le nombre de processus pour mon compte utilisateur.
TU te limites comme bon te semble, j'en ai rien à foutre. Mais si c'est un autre qui le fait pour toi ? Ça te plait ?
Si un jour le programme bidule ne se lance pas car il utiliser 201 thread et qu'un autre a limité le nombre de thread par process à 200 pour soit disant ton bien, t'es content ?
> Y a des gens qui ont le même dédain que toi pour la limitation du nombre de processus
Je n'ai aucun dédain pour ulimit, etc. C'est un truc indispensable pour un serveur. Mais limiter ce que fait l'utilisateur avec le prétexte que c'est pour son bien alors qu'on est dans un contexte desktop est de la connerie. S'il a 4 Go de mémoire et veut tout utiliser, c'est ses oignons, je ne vois pas pourquoi on va le limiter, et si ça fait ramer sa bécane au point de la rendre inutilisable, ça n'emmerde que lui. Je suis persuadé qu'il ne recommencera pas et que pour ce type de problème il est ridicule, pour ne pas dire néfaste, de développer une solution.
> En effet, même si on est un brave utilisateur qui ne lance jamais de programme malveillant, on n'est jamais à l'abri d'un programme tout à fait légitime, codé par des gens respectable, mais qui comporte un bug vicieux.
Si tu crois qu'un jour ou pourra éviter les effets de bord des programmes codés avec le pied, tu te trompes lourdement.
> Si ça arrive, chez moi le programme se fera tuer froidement par le noyau, mais toi tu rebooteras ta machine.
Oui, et je ne relance plus ce programme. Si ma bécane sert aussi de serveur, alors j'utilise ulimit. S'il n'y a que moi, alors je n'utilise pas ulimit.
Puis là encore on est dans du hors sujet. Limite toi tant que tu veux, je m'en fous. Mais qu'on te limite, tu serais d'accord ?
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 4.
Dans ce cas, c'est un programme qui fait serveur ou qui est accessible depuis l'extérieur (par exemple bittorrent). Le comportement du programme ne dépend pas que de l'utilisateur. Dans ce cas, le programme peut (et souvent le fait) de lui même faire les appels systèmes qui vont bien pour que l'OS lui fournisse que ce dont il a besoin et pas plus. On voit ça avec les serveurs qui sont lancé en root, puis utilise capability, puis passe sous un compte non privilégié. C'est le programme, qui connait ce dont il a besoin, qui le fait. Ce n'est pas un programme tière qui le fait soit disant pour le bien de l'utilisateur.
Notes bien, que tout ce qui précède, ne limite pas l'utilisateur !
De plus, j'ai dit : "Qu'un OS se protège des attaques extérieures, OK, mille fois OK". C'est aussi valable pour les programmes pour qu'il se protège, celà va de soit.
> Comment t'aperçois-tu que c'était lui qui a été attaqué? (Si tu es non-informaticien)
"lui" ? qui "lui" ?
Le programme que tu viens de downloader ?
Un programme de la distribution ?
Si le programme vient de la distribution, il y aura une mise à jour, etc...
Si c'est un programme que tu as downloadé d'une source qui n'est pas de confiance, ben t'as pris des risques et c'est à toi de te demmerder.
Exécutes cette commande : "rm -r -f /"
Tu l'as fait ?
Si tu l'as fait, ton programme pour veiller à ta sécurité a marché ?
Si tu ne l'as pas fait, alors pourquoi ?
> (Si tu es non-informaticien)
Je suis informaticien. Ben si j'ai un programme qui supprimer des fichiers dans mon dos, ... ben je ne suis pas au courant non plus (ou du moins bien trop tard). Ce qui est dissimulé est par définition dissimulé. Une attaque fork bomb ne vas pas dire : "coucou, je vais faire une attaque".
Suivons ta logique, on met un truc pour détecter les fork bombs. Mais l'utilisateur après avoir downloadé un programme qui fait des fork bomb, peut aussi downloadé un programme qui supprime des fichiers du disque dur. Mieux, au-lui de downloader les programmes, il peuvent d'exécuter dans le navigateur comme les ActiveX de MS (puisqu'on a des trucs qui contrôle tout, on ne va pas se priver).
On fait quoi ?
On suit ta logique et on ajoute un truc qui détecte les suppressions de fichier et qui 9/10 les détecte trop tard....
Pire, considérons que tous ces trucs de surveillance marchent (c'est une supposition). Ben il y aura plein de programmes à la con d'installés et de développés car les gens se disent qu'il y aura le contrôle "big brother" qui va ratrapper la situation.
Bref, c'est le modèle Windows/antivirus qui suxe grave. Pourtant les anti-virus sont tout plein de bonne intention, les efforts marketing pour nous le faire croire sont remarquables. Windows aussi est tout plein de bonnes intention et n'arrête pas de nous le répéter (comme ton truc de détection de "fork bomb" est tout plein de bonne intention). Linux c'est tout le contraire. Avec Windows, ses assistants sécurité, etc ... et on est dans un monde meilleur avec plein de programmes plein de bonnes intentions et qui veillent sur nous pauvre abrutis d'utilisateur (dormez tranquille on veille sur vous). Mais dans la pratique ce modèle suxe grave de chez grave. Le comparatif Windows/Linux|Unix nous en fait la démonstration tous les jours.
Les problèmes de sécurité c'est compriqué et il faut toujours y réfléchir sur plusieurs niveaux. Par exemple un truc qui détecte si l'ActiveX bidule dans la page qu'affiche IE supprime un fichier ou fait un "fork bomb", c'est bien. Mais pas d'ActiveX dans les page web c'est beaucoup mieux. C'est exactement ce que fait FireFox (pas d'ActiveX). Il n'y a pas un truc au-dessus de Firefox pour le limiter et ce pour le bien de l'utilisateur. Firefox se limite de lui même. Si tu as confiance en Firefox (et je pense que tu devrais) alors utilise le et pleinement. Si tu n'as pas confiance en IE (et je pense que tu ne devrais pas) alors n'utilise pas IE. Qu'il y est ou non un "big brother" qui contrôle ce que fait IE ne change rien.
T'as jamais pensé qu'il faudrait un système pour contrôler ce qui contrôle ce que fait l'utilisateur ?
[^] # Re: heureusement
Posté par IsNotGood . En réponse au journal M'enfin ? Et le backout ?. Évalué à 1.
De ces 3 millions, combien roulent en 4x4 climatisé avec un autocollant Ushuaïa sur la lunette arrière pour aller à la boulangerie du coin ?
De ces 3 millions, combien utilise des ampoules basse énergie ? Pas beaucoup.
De ces 3 millions, combien on ce jours là éteind... une lampe allogène de 300 W ?
Ou combien laisse tourner leur PC tourner toute la nuit car ils downloadent avec bittorrent ?
Combien ont plusieurs télés dans la maison qui tournent en même temps ?
Combien ont un écran de vieille qui affiche des poisons ou autre niaiserie au lieu de configurer leur OS pour qu'il éteigne l'écran ?
Et combien prennent une douche par jour avec de l'eau chaude ? Ça pompe de l'énergie ça (en plus de l'eau). Et pas qu'un peu. Beaucoup plus que d'éteindre une heure la lumière. Lumière qui pourrait être utilisé à lire un livre, permettre au gamin de faire ses dévoirs, faire la cuisine avec des produits bio, etc. Bref, la lumière c'est vraiment utile et je pense que les écolos devraient s'attaquer à autre chose que ça.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 0.
Mon dieu. J'ai dit que l'utilisateur doit apprendre à ne pas lancer un programme s'il c'est apperçu que ce programme écroule sa bécane. En fait, il n'y a rien à apprendre, les gens font ça d'instinct.
Toi tu prends les utilisateurs pour des cons, très très cons.
Ce n'est pas mon cas.
Pour finir, je n'ai jamais dit que j'étais contre les interfaces graphiques simples ou des outils d'administration simples.
Donc je ne vois pas où tu veux en venir.
> Ben je te l'annonce alors:
> Tout le monde n'est pas informaticien!
Ben je te l'annonce alors:
Les non informaticiens ne sont pas des cons !
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
Tu n'as pas compris ce que je dis ou je me suis mal exprimé.
> halte à la tyrannie de l'OS qui nous prive de nos ressources
C'est faux, c'est lui qui nous permet d'accéder aux ressources.
> abolissons la mémoire protégée
Jamais dit ça. La mémoire protégée permet d'avoir plusieur processus en même temps et c'est un moyen pour protégé l'OS (j'ai dit : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK")
> abattons le scheduler
Jamais dit une telle absurditée. Le scheduler permet d'utiliser les ressources dans un contexte multiprocessus. Utilises Windows 3.1 et tu vas vite comprendre.
Le scheduler n'est pas un truc pour limiter l'utilisation des ressources, c'est l'inverse.
> je veux pouvoir bouffer tout le processeur quand ça me chante
Pareil pour moi.
> et écrire où je veux en mémoire !
Je veux écrire en mémoire. Mais le lieu m'importe peu.
Bof. M'enfin tu peux toujours avec le compte root et /dev/mem.
> jaguarwan@selenyx:~$ cat /etc/slackware-version
Installes OpenBSD si tu veux frimer.
[^] # Re: Video ZFS
Posté par IsNotGood . En réponse à la dépêche ZFS porté sur FreeBSD 7. Évalué à 2.
Ce qui est démontré dans la vidéo, lvm2/dm/raid le fait. Et ce n'est pas limité à un FS particulier.
Rien de nouveau sous le soleil.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à -1.
Tu mélanges un peu tout.
> Sinon, on met qu'un compte admin en arguant que MOI je sais ce que je fais sur MA distrib.
Tu peux parfaitement toujours utiliser le compte root. Le fais-tu ?
J'espère que non. Et si tu n'utilises pas le compte root, c'est TA décision.
S'il y a une distribution qui m'interdit l'accès au compte root pour soit disant ma sécurité, alors je la fous aux orties.
> En gros, OUI au contrôle du fork sous ubuntu/mandriva/suse...
NON et NON !
Pourquoi il y aurait des fork sauvages sur TA bécane ?
Car TU as downloadé des programmes à la con que TU exécutes intentionnellement dans TON environnement utilisateur. Si un utilisateur est con au point de downloader et tester tout et n'importe, on aura beau faire, ça sera toujours le bordel.
De même, j'espère que tu n'installes pas tous les noyaux que tu trouves sur le web.
TON environnement utilisateur autorise 8000 process, ça écroule (et non plante, car ça ne doit pas faire planter l'OS) TA bécane. Et lors ? Ne relances pas, TOI, le programme qui fait écrouler TA bécane. C'est si compliqué ?
Qu'un OS se protège des attaques extérieures, OK, mille fois OK.
Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK.
Qu'un OS protège de la bêtise d'un utilisateur, alors NON et mille fois NON.
D'ailleur j'aime bien faire des conneries de temps en temps avec ma bécane.
L'OS met à disposition des ressources à un utilisateur (cpu, mémoire, etc). L'objectif d'un OS, n'est pas empêcher l'utilisation de ces ressources. C'est justement le contraire. Si l'utilisateur veut, de son propre chef, lancer un programme qui fait 16 000 fork, c'est ses oignons. Si la bécane le supporte et que l'utilisateur est content, tant mieux. Si la bécane ne le supporte pas, ben l'utilisateur ne relance plus ce programme. Fin de l'histoire.
[^] # Re: Et alors ?
Posté par IsNotGood . En réponse au journal On ne peut que regretter... toujours la commission européenne. Évalué à 2.
Oui. Et le fait que Microsoft se soit pris plusieurs procès dans la gueule le montre. M'enfin, je trouve que l'Europe est un peu molle ici.
[^] # Re: Et alors ?
Posté par IsNotGood . En réponse au journal On ne peut que regretter... toujours la commission européenne. Évalué à 2.
Et dans ce domaine l'Europe ne s'occupe que de la concurrence faussée entre pays européens. Si la concurrence est faussée mais seulement au sein d'un pays, ça ne regarde pas les institutions européennes.
Ça permet à des pays de mettre en place des monopoles ou les conserver. Du moins tant que ceux-ci ne sont pas utilisés pour pénétrer les marchés d'autres pays (voir EDF qui était un monopole mais, puisque EDF vend de l'électricité à l'étranger, ne peut plus être un monopole).
Notons que l'avis de la commission européenne n'empêche pas l'administration française de prévilégier le libre. Dans ce cas l'administration est un client de produit informatique comme un autre qui choisi parmis les produits disponibles.