Le Sun, 06 Jun 2004 22:59:48 +0000, Djoume SALVETTI a écrit :
Ouaip, Linus a préfèré les LSM (Linux Security Modules) pour sécuriser le noyau (cf selinux).
Le choix des LSM n'a rien à voir avec le fait que Linus aime ou n'aime pas les patches de sécurité. Il repose sur le fait que les mainteneurs du noyau ont préféré offrir une interface spécialisée pour ce type de fonctionnalités et ne pas avoir à gérer 15 produits différents inclus dans le noyau. D'où les LSM.
-- BOFH excuse #249:
Unfortunately we have run out of bits/bytes/whatever. Don't worry, the next supply will be coming next week.
Le Sun, 06 Jun 2004 22:59:48 +0000, Djoume SALVETTI a écrit :
Ouaip, Linus a préfèré les LSM (Linux Security Modules) pour sécuriser
le noyau (cf selinux).
Le choix des LSM n'a rien à voir avec le fait que Linus aime ou n'aime
pas les patches de sécurité. Il repose sur le fait que les mainteneurs
du noyau ont préféré offrir une interface spécialisée pour ce type de
fonctionnalités et ne pas avoir à gérer 15 produits différents inclus
dans le noyau. D'où les LSM.
--
BOFH excuse #249:
Unfortunately we have run out of bits/bytes/whatever. Don't worry, the
next supply will be coming next week.
Le Sun, 06 Jun 2004 22:59:48 +0000, Djoume SALVETTI a écrit :
Ouaip, Linus a préfèré les LSM (Linux Security Modules) pour sécuriser le noyau (cf selinux).
Le choix des LSM n'a rien à voir avec le fait que Linus aime ou n'aime pas les patches de sécurité. Il repose sur le fait que les mainteneurs du noyau ont préféré offrir une interface spécialisée pour ce type de fonctionnalités et ne pas avoir à gérer 15 produits différents inclus dans le noyau. D'où les LSM.
-- BOFH excuse #249:
Unfortunately we have run out of bits/bytes/whatever. Don't worry, the next supply will be coming next week.
Benjamin Pineau
Le 06 Jun 2004 19:51:17 GMT, Xavier Roche écrivais:
Oui et non. Il y a pas mal de problèmes d'incompatibilité avec les patchs sécurité et certaines applis. Par exemple serveur X et protection contre la pile executable de mémoire, ou encore la protection sur la mémoire partagée qui pose problème à d'autres (genre les problèmes de crash avec samba il y a de ça quelques temps).
Bref activer ces fonctionnalités "casse" certaines choses, et donc leur utilisation n'est pas totalement acceptée par tous.
D'où la pertinence de sa question: pourquoi préferer les patches (voir les entassements de patches), au résultat incertain, à un OS dont l'userland est maintenu par les developpeurs du noyau (et dont le noyau intègre d'emblée les fonctionalités sécu les plus pertinentes) avec donc un résultat stable garanti ? Le plaisir des architectures baroques ?
pourquoi ne pas choisir un os ou ces principes sont intégrés de base (au hasard, OpenBSD) ?
Moins "mainstream" ? Càd plus de problèmes avec les modules/drivers, compatibilité parfois plus difficile etc.
Il est plutôt rare de tomber sur du matériel serveur (cartes raid, scsi, réseau, crypto) non supporté. Et aucun driver n'est distribué sous forme de module (alors les problèmes de modules ....). Ah, il y a le jdk ...
Le 06 Jun 2004 19:51:17 GMT,
Xavier Roche <xroche@free.fr.NOSPAM.invalid> écrivais:
Oui et non. Il y a pas mal de problèmes d'incompatibilité avec les patchs
sécurité et certaines applis. Par exemple serveur X et protection contre
la pile executable de mémoire, ou encore la protection sur la mémoire partagée
qui pose problème à d'autres (genre les problèmes de crash avec samba il y
a de ça quelques temps).
Bref activer ces fonctionnalités "casse" certaines choses, et donc leur
utilisation n'est pas totalement acceptée par tous.
D'où la pertinence de sa question: pourquoi préferer les patches (voir
les entassements de patches), au résultat incertain, à un OS dont l'userland
est maintenu par les developpeurs du noyau (et dont le noyau intègre
d'emblée les fonctionalités sécu les plus pertinentes) avec donc un
résultat stable garanti ?
Le plaisir des architectures baroques ?
pourquoi ne pas choisir un os ou ces principes sont intégrés de base
(au hasard, OpenBSD) ?
Moins "mainstream" ? Càd plus de problèmes avec les modules/drivers,
compatibilité parfois plus difficile etc.
Il est plutôt rare de tomber sur du matériel serveur (cartes raid, scsi,
réseau, crypto) non supporté. Et aucun driver n'est distribué sous forme
de module (alors les problèmes de modules ....). Ah, il y a le jdk ...
Le 06 Jun 2004 19:51:17 GMT, Xavier Roche écrivais:
Oui et non. Il y a pas mal de problèmes d'incompatibilité avec les patchs sécurité et certaines applis. Par exemple serveur X et protection contre la pile executable de mémoire, ou encore la protection sur la mémoire partagée qui pose problème à d'autres (genre les problèmes de crash avec samba il y a de ça quelques temps).
Bref activer ces fonctionnalités "casse" certaines choses, et donc leur utilisation n'est pas totalement acceptée par tous.
D'où la pertinence de sa question: pourquoi préferer les patches (voir les entassements de patches), au résultat incertain, à un OS dont l'userland est maintenu par les developpeurs du noyau (et dont le noyau intègre d'emblée les fonctionalités sécu les plus pertinentes) avec donc un résultat stable garanti ? Le plaisir des architectures baroques ?
pourquoi ne pas choisir un os ou ces principes sont intégrés de base (au hasard, OpenBSD) ?
Moins "mainstream" ? Càd plus de problèmes avec les modules/drivers, compatibilité parfois plus difficile etc.
Il est plutôt rare de tomber sur du matériel serveur (cartes raid, scsi, réseau, crypto) non supporté. Et aucun driver n'est distribué sous forme de module (alors les problèmes de modules ....). Ah, il y a le jdk ...
Patrice Auffret
On 06 Jun 2004 19:51:17 GMT Emmanuel Florac wrote: [..]
Ça paraît évident. Sans compter que le type de grsecurity a annoncé que bien que ses développements soient GPL, il refuse que quelqu'un d'autre s'en charge, bref ça ne fait pas très sérieux de planter tout le monde plutôt que de repasser le bébé... [..]
Ca, ca ne m'étonne pas du tout. J'avais échangé quelques mails au sujet d'un comportement intéressant que je considérais comme un bug, et bonjour les réponses que j'ai eu: dignes d'un enfant.
On 06 Jun 2004 19:51:17 GMT
Emmanuel Florac <eflorac@imaginet.fr> wrote:
[..]
Ça paraît évident. Sans compter que le type de grsecurity a annoncé
que bien que ses développements soient GPL, il refuse que quelqu'un
d'autre s'en charge, bref ça ne fait pas très sérieux de planter tout
le monde plutôt que de repasser le bébé...
[..]
Ca, ca ne m'étonne pas du tout. J'avais échangé quelques mails au
sujet d'un comportement intéressant que je considérais comme un
bug, et bonjour les réponses que j'ai eu: dignes d'un enfant.
On 06 Jun 2004 19:51:17 GMT Emmanuel Florac wrote: [..]
Ça paraît évident. Sans compter que le type de grsecurity a annoncé que bien que ses développements soient GPL, il refuse que quelqu'un d'autre s'en charge, bref ça ne fait pas très sérieux de planter tout le monde plutôt que de repasser le bébé... [..]
Ca, ca ne m'étonne pas du tout. J'avais échangé quelques mails au sujet d'un comportement intéressant que je considérais comme un bug, et bonjour les réponses que j'ai eu: dignes d'un enfant.
Emmanuel Florac
Le Sun, 06 Jun 2004 22:59:22 +0000, Xavier Roche a écrit :
Son refus n'a aucune valeur, au passage, étant donné la license.
Certes mais comme en pratique le site n'est plus en ligne, qui a conservé toutes les sources, la doc, etc?
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Sun, 06 Jun 2004 22:59:22 +0000, Xavier Roche a écrit :
Son refus n'a aucune valeur, au passage, étant donné la license.
Certes mais comme en pratique le site n'est plus en ligne, qui a conservé
toutes les sources, la doc, etc?
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
Le Sun, 06 Jun 2004 22:59:22 +0000, Xavier Roche a écrit :
Son refus n'a aucune valeur, au passage, étant donné la license.
Certes mais comme en pratique le site n'est plus en ligne, qui a conservé toutes les sources, la doc, etc?
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Djoume SALVETTI
Le choix des LSM n'a rien à voir avec le fait que Linus aime ou n'aime pas les patches de sécurité. Il repose sur le fait que les mainteneurs du noyau ont préféré offrir une interface spécialisée pour ce type de fonctionnalités et ne pas avoir à gérer 15 produits différents inclus dans le noyau. D'où les LSM.
Oui mais Grsecurity n'utilise pas cette interface et n'a donc aucune chance de se voir intégré officiellement au noyau.
-- Djoumé SALVETTI
Le choix des LSM n'a rien à voir avec le fait que Linus aime ou n'aime
pas les patches de sécurité. Il repose sur le fait que les mainteneurs
du noyau ont préféré offrir une interface spécialisée pour ce type de
fonctionnalités et ne pas avoir à gérer 15 produits différents inclus
dans le noyau. D'où les LSM.
Oui mais Grsecurity n'utilise pas cette interface et n'a donc aucune
chance de se voir intégré officiellement au noyau.
Le choix des LSM n'a rien à voir avec le fait que Linus aime ou n'aime pas les patches de sécurité. Il repose sur le fait que les mainteneurs du noyau ont préféré offrir une interface spécialisée pour ce type de fonctionnalités et ne pas avoir à gérer 15 produits différents inclus dans le noyau. D'où les LSM.
Oui mais Grsecurity n'utilise pas cette interface et n'a donc aucune chance de se voir intégré officiellement au noyau.
-- Djoumé SALVETTI
Benjamin Pineau
Le 06 Jun 2004 22:59:48 GMT, Djoume SALVETTI écrivais:
Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la portabilité et surtout le manque de ports.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Si vous manquez de ports, vous pouvez toujours utiliser les pkgsrc de NetBSD (ok ils ne compilent pas tjrs parfaitement sous Open ; il faudrai faire des pr parraît-il).
Mais bon, comme d'hab, OpenBSD, GrSecurity, selinux, Windows, peu importe, l'important c'est de bien connaitre son système et de connaitre ses points faibles en termes de sécurité.
Ce n'est pas faux. Mais inssufisant. Le "bien connaitre" a ses limites: qui peut encore s'offrir le luxe d'auditer complétement le code de son OS et de ses services ? Et cet audit sera-t-il suffisant ? sans parler des OS où l'audit est impossible. Bref, on ne peut pas dire qu'être en mesure d'éviter les erreurs d'administration de débutant soit suffisant pour tout les besoins en termes de sécurité.
C'est où les mécanismes de sécurités étendus, objet de ce thread, trouvent leur raison d'être (de même que le rôle d'un firewall ne se limite pas à protéger contre les erreurs de débutants, services "oubliés" etc.).
Et c'est à ce titre que des questions de politique d'administration peuvent entrer en jeu dans le choix : qualité de l'integration avec l'OS, du support (tel patch/os, affaire d'un seul developpeur, sera-t-il abandoné ? est-il suffisament testé ? mon userland est-il bien compatible ? ), contraintes (casse-t-il le fonctionnement de tel logiciel ? de telle standard ou appel système normalisé ? etc.), de fonctionalités (si j'ai besoin d'IPsec, je n'ai que faire de Grsecurity ...). Et encore, de qualité de l'ensemble de l'architecture cible en fonction des solutions (e.g. je veut une protection par filtrage des appels systèmes, un stack IPsec de qualité, des MACs, quel est le choix le plus cohérent ?).
Pour répondre à d'autres posts encore: non, lids, les nsa/selinux, grsecurity, openbsd ou openwall ne sont en rien équivalents, ne sont pas substituables et n'offrent pas les mêmes fonctionalités de renforcement de la sécurité.
Le 06 Jun 2004 22:59:48 GMT,
Djoume SALVETTI <salvetti@crans.org> écrivais:
Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la
portabilité et surtout le manque de ports.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée
ce thread. Dites moi quelle architecture manque qui fasse objection au
déploiment de cet OS sur de serveurs modernes.
Si vous manquez de ports, vous pouvez toujours utiliser les pkgsrc de NetBSD
(ok ils ne compilent pas tjrs parfaitement sous Open ; il faudrai faire des
pr parraît-il).
Mais bon, comme d'hab, OpenBSD, GrSecurity, selinux, Windows, peu
importe, l'important c'est de bien connaitre son système et de connaitre
ses points faibles en termes de sécurité.
Ce n'est pas faux. Mais inssufisant. Le "bien connaitre" a ses limites:
qui peut encore s'offrir le luxe d'auditer complétement le code de son
OS et de ses services ? Et cet audit sera-t-il suffisant ? sans parler
des OS où l'audit est impossible. Bref, on ne peut pas dire qu'être en
mesure d'éviter les erreurs d'administration de débutant soit suffisant
pour tout les besoins en termes de sécurité.
C'est où les mécanismes de sécurités étendus, objet de ce thread,
trouvent leur raison d'être (de même que le rôle d'un firewall ne se
limite pas à protéger contre les erreurs de débutants, services
"oubliés" etc.).
Et c'est à ce titre que des questions de politique d'administration peuvent
entrer en jeu dans le choix : qualité de l'integration avec l'OS, du
support (tel patch/os, affaire d'un seul developpeur, sera-t-il abandoné ?
est-il suffisament testé ? mon userland est-il bien compatible ? ),
contraintes (casse-t-il le fonctionnement de tel logiciel ? de telle
standard ou appel système normalisé ? etc.), de fonctionalités (si j'ai
besoin d'IPsec, je n'ai que faire de Grsecurity ...). Et encore, de
qualité de l'ensemble de l'architecture cible en fonction des solutions
(e.g. je veut une protection par filtrage des appels systèmes, un stack
IPsec de qualité, des MACs, quel est le choix le plus cohérent ?).
Pour répondre à d'autres posts encore: non, lids, les nsa/selinux, grsecurity,
openbsd ou openwall ne sont en rien équivalents, ne sont pas substituables
et n'offrent pas les mêmes fonctionalités de renforcement de la sécurité.
Le 06 Jun 2004 22:59:48 GMT, Djoume SALVETTI écrivais:
Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la portabilité et surtout le manque de ports.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Si vous manquez de ports, vous pouvez toujours utiliser les pkgsrc de NetBSD (ok ils ne compilent pas tjrs parfaitement sous Open ; il faudrai faire des pr parraît-il).
Mais bon, comme d'hab, OpenBSD, GrSecurity, selinux, Windows, peu importe, l'important c'est de bien connaitre son système et de connaitre ses points faibles en termes de sécurité.
Ce n'est pas faux. Mais inssufisant. Le "bien connaitre" a ses limites: qui peut encore s'offrir le luxe d'auditer complétement le code de son OS et de ses services ? Et cet audit sera-t-il suffisant ? sans parler des OS où l'audit est impossible. Bref, on ne peut pas dire qu'être en mesure d'éviter les erreurs d'administration de débutant soit suffisant pour tout les besoins en termes de sécurité.
C'est où les mécanismes de sécurités étendus, objet de ce thread, trouvent leur raison d'être (de même que le rôle d'un firewall ne se limite pas à protéger contre les erreurs de débutants, services "oubliés" etc.).
Et c'est à ce titre que des questions de politique d'administration peuvent entrer en jeu dans le choix : qualité de l'integration avec l'OS, du support (tel patch/os, affaire d'un seul developpeur, sera-t-il abandoné ? est-il suffisament testé ? mon userland est-il bien compatible ? ), contraintes (casse-t-il le fonctionnement de tel logiciel ? de telle standard ou appel système normalisé ? etc.), de fonctionalités (si j'ai besoin d'IPsec, je n'ai que faire de Grsecurity ...). Et encore, de qualité de l'ensemble de l'architecture cible en fonction des solutions (e.g. je veut une protection par filtrage des appels systèmes, un stack IPsec de qualité, des MACs, quel est le choix le plus cohérent ?).
Pour répondre à d'autres posts encore: non, lids, les nsa/selinux, grsecurity, openbsd ou openwall ne sont en rien équivalents, ne sont pas substituables et n'offrent pas les mêmes fonctionalités de renforcement de la sécurité.
Djoume SALVETTI
Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la portabilité et surtout le manque de ports.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
N'importe laquelle qui ai plusieurs processeurs, et je doute que l'hyperthreading soit supporté.
Si vous manquez de ports, vous pouvez toujours utiliser les pkgsrc de NetBSD (ok ils ne compilent pas tjrs parfaitement sous Open ; il faudrai faire des pr parraît-il).
Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on commence à rajouter du code non officiellement supporté, Open pert beaucoup de son intéret (code audité, etc...).
-- Djoumé SALVETTI
Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la
portabilité et surtout le manque de ports.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée
ce thread. Dites moi quelle architecture manque qui fasse objection au
déploiment de cet OS sur de serveurs modernes.
N'importe laquelle qui ai plusieurs processeurs, et je doute que
l'hyperthreading soit supporté.
Si vous manquez de ports, vous pouvez toujours utiliser les pkgsrc de NetBSD
(ok ils ne compilent pas tjrs parfaitement sous Open ; il faudrai faire des
pr parraît-il).
Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on commence
à rajouter du code non officiellement supporté, Open pert beaucoup de
son intéret (code audité, etc...).
Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la portabilité et surtout le manque de ports.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
N'importe laquelle qui ai plusieurs processeurs, et je doute que l'hyperthreading soit supporté.
Si vous manquez de ports, vous pouvez toujours utiliser les pkgsrc de NetBSD (ok ils ne compilent pas tjrs parfaitement sous Open ; il faudrai faire des pr parraît-il).
Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on commence à rajouter du code non officiellement supporté, Open pert beaucoup de son intéret (code audité, etc...).
-- Djoumé SALVETTI
F. Senault
Le 06 Jun 2004 22:59:48 GMT, Djoume SALVETTI écrivais:
Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la portabilité et surtout le manque de ports.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est.
Mais bon, je dis ça, je dis rien.
Fred Suivi sur fcob, là. -- Sous la lumière en plein Et dans l'ombre en silence Si tu cherches un abri Inaccessible Dis toi qu'il n'est pas loin et qu'on y brille A ton étoile (Noir Désir, A ton étoile)
Le 06 Jun 2004 22:59:48 GMT,
Djoume SALVETTI <salvetti@crans.org> écrivais:
Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la
portabilité et surtout le manque de ports.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée
ce thread. Dites moi quelle architecture manque qui fasse objection au
déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un
serveur moderne (et moins moderne), je sais pas ce que c'est.
Mais bon, je dis ça, je dis rien.
Fred
Suivi sur fcob, là.
--
Sous la lumière en plein Et dans l'ombre en silence
Si tu cherches un abri Inaccessible
Dis toi qu'il n'est pas loin et qu'on y brille
A ton étoile (Noir Désir, A ton étoile)
Le 06 Jun 2004 22:59:48 GMT, Djoume SALVETTI écrivais:
Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la portabilité et surtout le manque de ports.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est.
Mais bon, je dis ça, je dis rien.
Fred Suivi sur fcob, là. -- Sous la lumière en plein Et dans l'ombre en silence Si tu cherches un abri Inaccessible Dis toi qu'il n'est pas loin et qu'on y brille A ton étoile (Noir Désir, A ton étoile)
Cedric Blancher
Le Mon, 07 Jun 2004 13:56:56 +0000, jdc a écrit :
On peut imaginer que ces braves gens de chez OpenBSD ne sont pas nécessairement des baltringues et qu'ils ont sacrifié un peu de peps au bénéfice de la robustesse et autres considérations nettement moins glamour.
Effectivement.
Un bipro pour faire une passerelle de sécu je veux bien, faut pas être rétrograde, mais bon.
Déjà, l'utilisation d'OpenBSD pour faire un firewall peut être discutée dans certains cas de figure. L'absence de support d'ALG comme FTP par exemple me semble cruellement manquer, d'autant que ce qui faisait sa force, le suivi de fenêtre TCP, est intégrable sous Linux. Enfin, pour une machine sur laquelle aucun port n'est ouvert...
L'intérêt que je vois à OpenBSD, c'est de mettre en place des serveurs applicatifs sécurisés, parce que les applications sont auditées, parce qu'on dispose d'outils audités efficace, etc. Mais si j'ai besoin d'un bipro parce que mon Web a besoin de puissance de calcul, ben paf. Considérer que le bipro est un guizmo à la mode me semble clairement _très_ rétrograde. Mais bon, ce n'est pas le genre d'argument qui me font travailler sur une autre plate-forme.
-- BOFH excuse #408:
Computers under water due to SYN flooding.
Le Mon, 07 Jun 2004 13:56:56 +0000, jdc a écrit :
On peut imaginer que ces braves gens de chez OpenBSD ne sont pas
nécessairement des baltringues et qu'ils ont sacrifié un peu de peps
au bénéfice de la robustesse et autres considérations nettement moins
glamour.
Effectivement.
Un bipro pour faire une passerelle de sécu je veux bien, faut pas être
rétrograde, mais bon.
Déjà, l'utilisation d'OpenBSD pour faire un firewall peut être
discutée dans certains cas de figure. L'absence de support d'ALG comme
FTP par exemple me semble cruellement manquer, d'autant que ce qui faisait
sa force, le suivi de fenêtre TCP, est intégrable sous Linux. Enfin,
pour une machine sur laquelle aucun port n'est ouvert...
L'intérêt que je vois à OpenBSD, c'est de mettre en place des serveurs
applicatifs sécurisés, parce que les applications sont auditées, parce
qu'on dispose d'outils audités efficace, etc. Mais si j'ai besoin d'un
bipro parce que mon Web a besoin de puissance de calcul, ben paf.
Considérer que le bipro est un guizmo à la mode me semble clairement
_très_ rétrograde. Mais bon, ce n'est pas le genre d'argument qui me
font travailler sur une autre plate-forme.
On peut imaginer que ces braves gens de chez OpenBSD ne sont pas nécessairement des baltringues et qu'ils ont sacrifié un peu de peps au bénéfice de la robustesse et autres considérations nettement moins glamour.
Effectivement.
Un bipro pour faire une passerelle de sécu je veux bien, faut pas être rétrograde, mais bon.
Déjà, l'utilisation d'OpenBSD pour faire un firewall peut être discutée dans certains cas de figure. L'absence de support d'ALG comme FTP par exemple me semble cruellement manquer, d'autant que ce qui faisait sa force, le suivi de fenêtre TCP, est intégrable sous Linux. Enfin, pour une machine sur laquelle aucun port n'est ouvert...
L'intérêt que je vois à OpenBSD, c'est de mettre en place des serveurs applicatifs sécurisés, parce que les applications sont auditées, parce qu'on dispose d'outils audités efficace, etc. Mais si j'ai besoin d'un bipro parce que mon Web a besoin de puissance de calcul, ben paf. Considérer que le bipro est un guizmo à la mode me semble clairement _très_ rétrograde. Mais bon, ce n'est pas le genre d'argument qui me font travailler sur une autre plate-forme.
-- BOFH excuse #408:
Computers under water due to SYN flooding.
Miod Vallat
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est.
C'est marrant, ces deux points sont justement en plein travail. Ceci dit, le SMP, ça te fait une belle jambe quand ton goulot d'étranglement est le débit du bus PCI.
Mais bon, je dis ça, je dis rien.
Tout pareil.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée
ce thread. Dites moi quelle architecture manque qui fasse objection au
déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un
serveur moderne (et moins moderne), je sais pas ce que c'est.
C'est marrant, ces deux points sont justement en plein travail. Ceci
dit, le SMP, ça te fait une belle jambe quand ton goulot d'étranglement
est le débit du bus PCI.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est.
C'est marrant, ces deux points sont justement en plein travail. Ceci dit, le SMP, ça te fait une belle jambe quand ton goulot d'étranglement est le débit du bus PCI.
