Et la zik est pas mal du tout cette fois-ci :
 
http://www.openbsd.org/lyrics.html

Salut axey,
Tu pourrais me donner ton point de vue sur OpenBSD ?
 
Voila, on sait tous qu'OpenBSD à la réputation d'être 'secure' par défaut et c'est ce que j'aime bien chez eux. Avoir des sources plus que sûres, je trouve ça terrible comme concept. Mais R@NNIS ( au passage, une personne du forum ) m'a ouvert l'esprit. Cela va de soit, mais si l'admin de la machine fait une connerie, quelque chose comme ouvrir certains ports qui ne devraient pas l'être, OpenBSD n'a plus d'intérêts que ces sources soit sécurisées ou non.
 
 
On peut donc remettre en question l'utilité d'OpenBSD. Ne vaut-il pas mieux préférer la mise en place d'un linux bien sécurisé plutôt qu'OpenBSD ? OpenBSD ne serait pas par hasard pour les administrateurs "fainéant" qui ne veulent pas configurer leur machine ?
 
Toi qui est plutôt bien placé dans le milieu, j'aurais aimé connaître ton point de vue sur ce système d'exploitation ainsi que ses avantages que tu lui vois et ses inconvénients que tu lui reproches.  
 
   
 
Que les autres n'hésitent pas à donner leur point de vue

mon point de vue perso -> sécuriser les serveurs, les workstation, tout ça, c'est bien
 
mais à terme, vu la multiplications des machines, je pense qu la seule solution viable sera de sécuriser au max la connex en hardware par des solutions firewall + proxy/cache genre le produit de bluecoat systems qui sécurise le port 80
 
non parce que devoir updater 30 000 machines à chaque failles de sécurité c chaud quand même

dofor a écrit a écrit : mon point de vue perso -> sécuriser les serveurs, les workstation, tout ça, c'est bien   mais à terme, vu la multiplications des machines, je pense qu la seule solution viable sera de sécuriser au max la connex en hardware par des solutions firewall + proxy/cache genre le produit de bluecoat systems qui sécurise le port 80   non parce que devoir updater 30 000 machines à chaque failles de sécurité c chaud quand même

 
C'est sûr. Mais bon, pas énormément de personnes sont chargés à eux seul de maintenir un parc informatique de 30 000 machines . Toujours est-il que même 10/50 machines c'est déjà énorme.  
 
 
Humff, après réfléxion, doit bien y exister des solutions à ce genre de problème.

oui evidemment
 
mais dans tous les cas c une galère...
 
perso je préfère centraliser la sécu... on dit souvent que la sécurité d'un réseau se mesure à son maillon le plus faible (:D)
ben autant centraliser et renforcer à mort non?
 
je ne remets pas en cause l'intérêt des OS sécure, au contraire ça fait un bon complément
 
mais ça ne reste pour moi qu'un complément...

Un complément oui. C'est sans doute le meilleur mot aproprié.

J'ai vu sur linuxfr.org que le portage de openbsd vers la debian avait été abandonner donc linux est devenu aussi secure qu'un openbsd (enfin si j'ai bien compris ?? )

 
Je pourrais pas vraiment te répondre car en fait j'en sais rien.
 
Mais il est interessant de lire les commentaires de cette news sur linuxfr : http://linuxfr.org/2002/11/01/10077.html

A noter que 'Jar Jar Binks' (est ce le Jar Jar d'ici ?) parle du noyau de BSD comme d'une 'usine à trous de sécurité.'.
 
J'avoue que je comprends pas    Une usine à trous de sécurité ? Que penser du slogan qu'ils affichent sur le site officiel d'OpenBSD, à savoir 'One remote hole in the default install, in nearly 6 years!' ?
 
C'est peu cohérent tout ça. Si quelqu'un à des explications  

localhost a écrit a écrit : A noter que 'Jar Jar Binks' (est ce le Jar Jar d'ici ?) parle du noyau de BSD comme d'une 'usine à trous de sécurité.'.   J'avoue que je comprends pas    Une usine à trous de sécurité ? Que penser du slogan qu'ils affichent sur le site officiel d'OpenBSD, à savoir 'One remote hole in the default install, in nearly 6 years!' ?   C'est peu cohérent tout ça. Si quelqu'un à des explications

C'ezt bien la même personne. Il ne faisait que reporter les propos qui ont été tenus sur la ML Debian/OpenBSD. Lis l'article de DLFP et les liens, tu en sauras un peu plus.

Y aurait-il une guerre Debian/OpenBSD ?

Un avis à 5 kopeks
 
c'est du côté des hommes que ça merde le plus, pas de côté des machines
 

... un bsd possède une architecture un poil plus robuste que linux mais les differences tendent effectivement à diminuer ...
 
... pour moi ça reste toujours plus rapide que linux dans le cadre d'un serveur en utilisation intensive pour le reste c'est moins évident ...

Ca me paraît plus 'manuel' et surtout moins bordélique comme architechture ... d'ailleurs, il n'y a pas que OpenBSD, mais aussi FreeBSD et NetBSD. Quand JarJar dit que LE noyau BSD est une usine à trous de sécurité (expression à deux balles d'ailleurs ...) j'aîmerais bien savoir de quel noyau il parle. Parce que l'architechture BSD 4.4 est plutôt robuste, et plus suivie que Linux qui n'a que certaines conventions, que toutes les distrib' ne suivent pas ...
BSD spa vraiment pour les Desktop Users, mais en tant que serveur c'est vraiment le pied.

Euh...
 
"Le noyau BSD a une architecture robuste" ca ne veut pas dire grand chose concretement.
 
En pratique, programmer des trucs sur le noyau Linux est beaucoup plus agreable que sur un noyau BSD. Sous Linux, il y a des couches d'abstraction pour tout, qui sont bien compartimentees et bien documentees. Il y a d'office plein de fonctions a disposition pour gerer les structures de donnees courantes, implementer un cache, effectuer des operations asynchrones, placer des verrous sans risque de deadlock, etc. Toutes ces fonctions sont reentrantes, prevues pour fonctionner en SMP, elles peuvent etre utilisees dans des gestionnaire d'interruption sans precaution particuliere, etc. Pareil, quand on a besoin de memoire, il y a une batterie de fonction generiques pour repondre a tous les besoins. Au niveau debogguage, quand un thread du noyau plante, c'est sans consequence. Quand un spinlock s'eternise, il peut finir par etre automatiquement deverouille. Quand on essaye d'acceder a une page deja liberee, le noyau peut continuer a fonctionner quand meme.
 
Sous BSD (du moins Open/Micro), c'est plus limite. Les fondations sont reduites au strict minimum. Pour les allocations de memoire courantes, le seul truc a disposition c'est les fonctions pool* qui sont pourries pour les trucs dynamiques. La couche d'abstraction des systemes de fichiers est tres basique et oblige a reinventer la roue a chaque fois pour les locks. Si l'on veut faire un truc un peu particulier (comme de ne pas passer par le cache, comme O_DIRECT sous Linux), c'est un travail de cingle, il faut completement revoir les vfsops. Ca ne facilite pas du tout l'integration d'un systeme journalise par exemple. Et quand il y a un truc incoherent dans un test, il est difficile de dire au noyau d'essayer de continuer son boulot, la seule fonction que l'on peut appeler c'est panic() qui cause un kernel panic. Une merde dans un driver, ca fait tout planter, c'est chiant pour debugguer.
 
Un autre truc super gonflant dans les noyaux BSD : le manque de typage. Dans Linux il y a un type pour chaque truc. C'est un peu gonflant au debut et on s'y paume rapidement, mais d'une part ca permet d'etendre les trucs facilement, d'autre part ca permet d'eviter des erreurs betes. Dans un noyau BSD, pour n'importe quoi, on utilise un peu arbitrairement toujours les memes types : int, u_int et u_int32_t. Quand on melange deux variables sans rapport sans faire gaffe, le compilateur est incapable de nous prevenir. Et quand on se plante sur le type (on a pris un type non signe alors que l'utilisateur peut passer des trucs signe), c'est tres chiant a corriger, il faut vraiment faire gaffe a changer les bons int en u_int et pas les autres. Il y a eu pas mal de failles de secu sur les BSD a cause de ca (dans le filesystem sous FreeBSD, dans des appels comme itimer sous OpenBSD, etc) .
 
Autant les couches d'abstraction et les types dans tous les sens sous Linux sont reloues au debut (et en plus ca change sans arret, il faut suivre...), autant ca permet d'eviter du bricolage intempestif comme sous BSD. Deplacer ou recopier une partie d'un filesystem (mount --bind, mount --move) sous Linux, ca prend trois lignes (et ca fonctionne en smp) car la vfs est suffisemment generique pour ca. Sous BSD il faut reimplementer un nouveau filesystem virtuel qui va lui-meme lire les donnees d'un autre filesystem deja present, tout en trafiquant pour qu'il ne soit jamais possible d'ecrire dans les deux au meme moment. C'est du bricolage, et d'ailleurs ca ne fonctionne toujours pas correctement.
 
Bon, tout ca c'est bien gentil, mais c'est du blabla. Dans les faits, et malgre une architecture beaucoup plus propre dans Linux que dans les noyaux BSD, il n'y a pas tellement de difference. Sous Linux, c'est simple de changer completement une partie importante comme le gestionnaire de memoire virtuelle, le scheduler, etc. sans toucher au reste. Du coup, bein... ca n'arrete pas. L'infrastructure ne bouge pas trop, mais tout ce qui va au dessus change sans cesse, pour implementer de nouvelles idees, pour essayer des trucs plus performants, etc. Et on obtient un ensemble pas forcement hyper solide a cause de ca.
 
Et quand l'infrastructure bouge sous Linux, c'est la panique. Quand j'ai fait le filesystem de QNX, c'etait a l'epoque des noyaux 2.2.X et 2.3.X, et quelques semaines plus tard, l'interface de la vfs (la colle entre les filesystems et les drivers) a change. L'ext2 a ete adapte a la nouvelle interface, mais les autres filesystems ont eu enormement de mal a completement migrer. Pour le qnx4fs, j'avais vaguement modifie le code d'apres celui de l'ext2, mais il restait des appels a des fonctions de l'"ancienne" infrastructure qui donnaient un truc instable. Ca a ete la meme merde plus tard puissance 10 pour ReiserFS et c'etait d'ailleurs l'une des raisons qui a retarde son integration dans le noyau.
 
Sous BSD, ce genre de changement est necessaire tout le temps. Par exemple l'introduction du cache unifie (UBC) dans NetBSD et OpenBSD, ca a necessite de reprendre fichier par fichier tout ce qui faisait appel de pres ou de loin au gestionnaire de memoire. Il y a eu des oublis qui ont cause des bogues aleatoires impossibles a localiser. C'est pour ca que l'UBC est integre depuis 1 ans dans OpenBSD, mais toujours pas utilise. Art s'est remis au boulot recemment, en rechangeant tout, et en se resynchronisant sur NetBSD, car les bogues etaient vraiment trop chiants a trouver... trop disperses (encore une fois a cause du manque de compartimentation et de couches d'abstraction sous BSD. Sous Linux, c'est beaucoup plus simple de localiser ce type de bogue) .
 

ah bah j'ai du boulot avant d'en savoir autant que toi !  
 

 
quand tu dis ça il me vient une question : tous ces changements ne sont pas documenté quelque part ?  
parce que ça fait bordelique vu comme ça
 
sinon, tu penses quoi des appréciations qu'on peut trouver dans le man de nmap où il est dit que openbsd (parmi beaucoup d'autre bien sur) ne respecte pas pleinement le protocol ip ?
l'option -sW notamment de nmap 3 ?

Il faut lire les mailing-list.

 
ouai bah on a vu mieux comme documentation