Primo, si il y a tellement de races conditions, et que cela l'air d'etre connu, pourquoi est ce que personne n'en parle ?
Enfin, je veut de dire, des autres, car j'en ai trouvé une pour OpenBSD 3.1, une dans le 3.0, et 2 pour le 2.9 sur la page d' opensd.org ( http://www.openbsd.org/security.html(...) , section advisories )
Effectivement, c'est beaucoup 4 race conditions en 1 an et demi...
Je sais pas combien il y en a eu pour le noyau linux durant cette période, et j'ai pas le temps de faire les recherches pour ca.
Mais, a vu de nez, surement plus que 4....
Secundo, si les logiciels de bases ne sont pas plus sécurisés que les logiciels gnu, pourquoi a t'on trouvé une faille dans GNU tar et pas dans le tar d'OpenBSD ?
Tertio, OpenBSD ne supporte aps le format Elf et alors ?
C'est si compliqué de rajouter une option a cc pour compiler en a.out ?
Peut etre meme que l'option par defaut du compilo d'openbsd ?
Peut etre meme que le ./configure le detecte ?
Je ne connait pas les subtiles differences entre les deux, mais, sauf erreur de ma part, OpenBsd peut lancer les binaires Linux ( et autres ), des binaires au format.... ELF.
Et il supporte les bibliothéques au format .so , qui est basés sur ELF si je ne m'abuse.
Et dire que le format a.out est dépassé, je te ferais remarqué que FreeBSD est passé au format elf uniquement car l'équipe de gcc a arreté de supporté a.out....
Quand je disait défense en profondeur, c'etait pas forcément integrée au noyau.
J'imagine par exemple, que le hashage des executables sur netbsd ( voir http://www.netbsd.org/Changes/#veriexec_021029(...) ), peut sans aucun probleme etre fait dans la glibc. La, c'est fait dans le noyau, bon, ben c'est leur droit.
Je sais que je n'ai pas donné de bons exemples, mais pour moi, la defense en profondeur, ca recouvre aussi l'utilisation de biblis spéciales, comme libsafe ( si je dit pas de conneries ).
C'est, par exemple, Minas-Tirith et ses 7 murailles ( Le seigneurs des anneaux ).
C'est un coffre fort ET un systéme d'alarme.
Pour rentrer faut couper l'alarme et forcer le coffre.
Et ca semble complexe, mais si on fait les choses correctement ( du point de vue du design ) , c'est fait de maniére transparente. Pe pas sans recompilation, mais, au moins de maniere transparente
Ton login, qu'il utilise libsafe, ou qu'il utilise pas libsafe, ca devrait changer globalement rien pour lui.
Tout juste une option de compilation.
C'est comme le fait de lancer un programme avec valgrind, le programme ne le voit pas, sauf peut etre si il le fait exprés, ce qui est rarement le cas.
En plus, ca permet de subdiviser le boulot correctement.
C'est sur, c'est plus dur de securiser un reseau et des machines mais , c'est parce qu'il y a plus de boulot. Je suis d'accord, la complexité n'est pas inhérente a la sécurité, c'est inhérent a la taille du systéme.
Si une personne se charge du reseau et que du reseau, et une autre des machines et que des machines, c'est tout de meme plus secure, que si il n'y avait que de la securite sur le reseau, ou que sur les machines, non ?
Je suis d'accord qu'au bout d'un moment, tu ne peut plus avoir de vue global. Et je suis aussi d'accord que la securite total, ca n'existe pas. Je ne voulait pas dire ca dans le sens d'absolu, mais dans le sens, le mieux que tu puisse obtenir, une securite maximum. Mais cette securite maximum, on ne peut pas , a mon avis, l'obtenir avec une seule couche de securite.
Pe pas dans le noyau, c'est sur.
Mais, ca c'est une question d'implementation.
Un truc pourri, dans le noyau ou a coté, ca reste un truc pourri....
Des choses comme crypter la partition de swap, je voit mal ou le placer hors du noyau... ( OK, ca sert un peu a rien, c'est joli, mais ca ne va pas changer nos vies. Désolé, c'est le seul exemple que je voit a la fois simple et dans le noyau ).
L'endoit ou se trouve la couche de sécurité, c'est peu important. L'important c'est que ce soit la, et que ca marche.
Bien sur, un fonctionnalité qui empeche un bug dans login ne fait pas disparaitre le probléme de login.
Mais, c'est de la défense en profondeur.
Si tu mets un firewall, et qu 'il tombe, et que derriére, tes bécanes sont sécurisées et incrackables ou du moins, difficilement crackables , ben voila, tu es quand meme moins dans la merde.
De la même facon, mettre des fonctionnalités de sécurités dans le noyau, comme cette histoire de pile non executable, c'est pas une excuse pour ne pas programmer proprement, c 'est juste un truc en plus pour le cas ou.
Bien sur c'est pas infaillible, mais c'est toujours mieux que si il n'y avait rien, non ?
On a jamais demandé de faire un choix entre des bons programmes, ou un bon OS, ou un processeur securisé.
Si on veut la sécurité total, il faut les trois.
Des programmes sur, tournant par dessus un OS sur, avec, quand ca existera , un processeur securisé.
Bien sur, dans la réalité,il faut faire des choix.
et c'est la que le facteur humain intervient.
Il faut des personnes compétentes, pluto que des programmes de sécurité qui font le café.
Mais meme avec le plus competent des administrateurs, si il n'a pas de ssh pour eviter de sniffer les mots de passes, ca sert a rien.
Le facteur humain, bien sur, mais avec des moyens corrects.
Meme si les services marketing enjolivent trop les produits, il ne faut pas oublier que c'est pas eux qui ont eu l'idée ( j'espere ). Et donc, qu'au départ, toute fonctionnalité est sensée repondre a un besoin.
Par exemple, par défaut, apache tourne en chroot.
De meme, comme toute les distribs modernes, il lance le moins de services par defaut, et réalise des audits de securité régulierement.
Bien sur, c'est rien de spécial, vu que ce ne sont pas les seuls a le faire.
Concernant la réactivité aux bugs, d'aprés le site web d'OpenBSD, ils font des recherches actives pour trouver les problémes avant qu'ils ne deviennent exploitables.
Et ne cache pas d'infos.
Ca aussi, c'est rien, car tout le monde fait ca maintenant.
Mais ils clament qu'ils font ca depuis toujours.
Concernant des trucs comme palladium, je suis désolé de dire ca, mais du point de vue sécurité, ca ne serait pas mal SI ( et j'insiste sur le si ), et seulement SI on nous laisse le choix.
Mais celui de Disney et des musiques écoutables trois fois, c'est bien plus génant.
Le probléme, c'est qu'effectivment, ca a plus de chance de tuer nos libertés que de nous servir....
Sincérement, si on nous laisse le choix de prendre un processeur avec des fonctionnalités de sécurités, correctement implementés, et documentés, avec en parraléle, un proc normal, ca ne me pose pas de problémes.
Imaginez un proc qui empeche le buffer overflow. Et qui verifie la provenance du code, ou, comme sur NetBsd, le hachage d'un executable.
Ou bien qui blinde le noyau de maniére hard ( comme un des patch du noyau, dont j'ai oublié le nom , lids, je croit ).
Tu prendrais un proc secure pour les ordis de ton boulot de chef de sécurité à la banque et un proc normal pour ta bécane et voila.
sauf que, effectivement, on veut nous forcer a prendre Palladium...
Le niveau de sécurité d'une Débian est peut etre comparable a celui d'OpenBSD, mais je tient a rappeler tout de meme
que le noyau d'OPenBSD propose des fonctionnalités assez interessantes :
il est probable que la plupart des ces fonctionnalités ( notamment la derniére ) existent sous linux.
mais, est ce qu'une distribution les propose par defaut ?
je ne parle pas d'une distrib confidentiel ( engarde linux, etc etc), mais d'une des 5 distribs les plus utilisés.
Pas a ma connaissance.
[^] # Re: Debian/OpenBSD s'arrête, les autres ports BSD continuent
Posté par Misc (site web personnel) . En réponse à la dépêche Debian/OpenBSD s'arrête, les autres ports BSD continuent. Évalué à 1.
Enfin, je veut de dire, des autres, car j'en ai trouvé une pour OpenBSD 3.1, une dans le 3.0, et 2 pour le 2.9 sur la page d' opensd.org ( http://www.openbsd.org/security.html(...) , section advisories )
Effectivement, c'est beaucoup 4 race conditions en 1 an et demi...
Je sais pas combien il y en a eu pour le noyau linux durant cette période, et j'ai pas le temps de faire les recherches pour ca.
Mais, a vu de nez, surement plus que 4....
Secundo, si les logiciels de bases ne sont pas plus sécurisés que les logiciels gnu, pourquoi a t'on trouvé une faille dans GNU tar et pas dans le tar d'OpenBSD ?
http://online.securityfocus.com/archive/1/196445(...)
Tertio, OpenBSD ne supporte aps le format Elf et alors ?
C'est si compliqué de rajouter une option a cc pour compiler en a.out ?
Peut etre meme que l'option par defaut du compilo d'openbsd ?
Peut etre meme que le ./configure le detecte ?
Je ne connait pas les subtiles differences entre les deux, mais, sauf erreur de ma part, OpenBsd peut lancer les binaires Linux ( et autres ), des binaires au format.... ELF.
Et il supporte les bibliothéques au format .so , qui est basés sur ELF si je ne m'abuse.
Et dire que le format a.out est dépassé, je te ferais remarqué que FreeBSD est passé au format elf uniquement car l'équipe de gcc a arreté de supporté a.out....
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#AOUT(...)
D'aprés leur FAQ, ils n'avait pas de probléme au point de devoir changer, contrairement a Linux.
http://people.freebsd.org/~nik/advocacy/myths.html#aout(...)
Ca c'est des arguments fondés.
C'est pas des affirmations gratuites non étayés....
[^] # Re: Debian/OpenBSD s'arrête, les autres ports BSD continuent
Posté par Misc (site web personnel) . En réponse à la dépêche Debian/OpenBSD s'arrête, les autres ports BSD continuent. Évalué à 1.
J'imagine par exemple, que le hashage des executables sur netbsd ( voir http://www.netbsd.org/Changes/#veriexec_021029(...) ), peut sans aucun probleme etre fait dans la glibc. La, c'est fait dans le noyau, bon, ben c'est leur droit.
Je sais que je n'ai pas donné de bons exemples, mais pour moi, la defense en profondeur, ca recouvre aussi l'utilisation de biblis spéciales, comme libsafe ( si je dit pas de conneries ).
C'est, par exemple, Minas-Tirith et ses 7 murailles ( Le seigneurs des anneaux ).
C'est un coffre fort ET un systéme d'alarme.
Pour rentrer faut couper l'alarme et forcer le coffre.
Et ca semble complexe, mais si on fait les choses correctement ( du point de vue du design ) , c'est fait de maniére transparente. Pe pas sans recompilation, mais, au moins de maniere transparente
Ton login, qu'il utilise libsafe, ou qu'il utilise pas libsafe, ca devrait changer globalement rien pour lui.
Tout juste une option de compilation.
C'est comme le fait de lancer un programme avec valgrind, le programme ne le voit pas, sauf peut etre si il le fait exprés, ce qui est rarement le cas.
En plus, ca permet de subdiviser le boulot correctement.
C'est sur, c'est plus dur de securiser un reseau et des machines mais , c'est parce qu'il y a plus de boulot. Je suis d'accord, la complexité n'est pas inhérente a la sécurité, c'est inhérent a la taille du systéme.
Si une personne se charge du reseau et que du reseau, et une autre des machines et que des machines, c'est tout de meme plus secure, que si il n'y avait que de la securite sur le reseau, ou que sur les machines, non ?
Je suis d'accord qu'au bout d'un moment, tu ne peut plus avoir de vue global. Et je suis aussi d'accord que la securite total, ca n'existe pas. Je ne voulait pas dire ca dans le sens d'absolu, mais dans le sens, le mieux que tu puisse obtenir, une securite maximum. Mais cette securite maximum, on ne peut pas , a mon avis, l'obtenir avec une seule couche de securite.
Pe pas dans le noyau, c'est sur.
Mais, ca c'est une question d'implementation.
Un truc pourri, dans le noyau ou a coté, ca reste un truc pourri....
Des choses comme crypter la partition de swap, je voit mal ou le placer hors du noyau... ( OK, ca sert un peu a rien, c'est joli, mais ca ne va pas changer nos vies. Désolé, c'est le seul exemple que je voit a la fois simple et dans le noyau ).
L'endoit ou se trouve la couche de sécurité, c'est peu important. L'important c'est que ce soit la, et que ca marche.
J'espere etre pas trop obscur sur ce coup ci.
[^] # Re: Debian/OpenBSD s'arrête, les autres ports BSD continuent
Posté par Misc (site web personnel) . En réponse à la dépêche Debian/OpenBSD s'arrête, les autres ports BSD continuent. Évalué à 1.
Mais, c'est de la défense en profondeur.
Si tu mets un firewall, et qu 'il tombe, et que derriére, tes bécanes sont sécurisées et incrackables ou du moins, difficilement crackables , ben voila, tu es quand meme moins dans la merde.
De la même facon, mettre des fonctionnalités de sécurités dans le noyau, comme cette histoire de pile non executable, c'est pas une excuse pour ne pas programmer proprement, c 'est juste un truc en plus pour le cas ou.
Bien sur c'est pas infaillible, mais c'est toujours mieux que si il n'y avait rien, non ?
On a jamais demandé de faire un choix entre des bons programmes, ou un bon OS, ou un processeur securisé.
Si on veut la sécurité total, il faut les trois.
Des programmes sur, tournant par dessus un OS sur, avec, quand ca existera , un processeur securisé.
Bien sur, dans la réalité,il faut faire des choix.
et c'est la que le facteur humain intervient.
Il faut des personnes compétentes, pluto que des programmes de sécurité qui font le café.
Mais meme avec le plus competent des administrateurs, si il n'a pas de ssh pour eviter de sniffer les mots de passes, ca sert a rien.
Le facteur humain, bien sur, mais avec des moyens corrects.
Meme si les services marketing enjolivent trop les produits, il ne faut pas oublier que c'est pas eux qui ont eu l'idée ( j'espere ). Et donc, qu'au départ, toute fonctionnalité est sensée repondre a un besoin.
[^] # Re: Debian/OpenBSD s'arrête, les autres ports BSD continuent
Posté par Misc (site web personnel) . En réponse à la dépêche Debian/OpenBSD s'arrête, les autres ports BSD continuent. Évalué à 1.
Par exemple, par défaut, apache tourne en chroot.
De meme, comme toute les distribs modernes, il lance le moins de services par defaut, et réalise des audits de securité régulierement.
Bien sur, c'est rien de spécial, vu que ce ne sont pas les seuls a le faire.
Concernant la réactivité aux bugs, d'aprés le site web d'OpenBSD, ils font des recherches actives pour trouver les problémes avant qu'ils ne deviennent exploitables.
Et ne cache pas d'infos.
Ca aussi, c'est rien, car tout le monde fait ca maintenant.
Mais ils clament qu'ils font ca depuis toujours.
Concernant des trucs comme palladium, je suis désolé de dire ca, mais du point de vue sécurité, ca ne serait pas mal SI ( et j'insiste sur le si ), et seulement SI on nous laisse le choix.
L'exemple de la classification des documents pour l'armée ( http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html(...) ) n'est pas a priori liberticide.
Mais celui de Disney et des musiques écoutables trois fois, c'est bien plus génant.
Le probléme, c'est qu'effectivment, ca a plus de chance de tuer nos libertés que de nous servir....
Sincérement, si on nous laisse le choix de prendre un processeur avec des fonctionnalités de sécurités, correctement implementés, et documentés, avec en parraléle, un proc normal, ca ne me pose pas de problémes.
Imaginez un proc qui empeche le buffer overflow. Et qui verifie la provenance du code, ou, comme sur NetBsd, le hachage d'un executable.
Ou bien qui blinde le noyau de maniére hard ( comme un des patch du noyau, dont j'ai oublié le nom , lids, je croit ).
Tu prendrais un proc secure pour les ordis de ton boulot de chef de sécurité à la banque et un proc normal pour ta bécane et voila.
sauf que, effectivement, on veut nous forcer a prendre Palladium...
# Re: Debian/OpenBSD s'arrête, les autres ports BSD continuent
Posté par Misc (site web personnel) . En réponse à la dépêche Debian/OpenBSD s'arrête, les autres ports BSD continuent. Évalué à 1.
que le noyau d'OPenBSD propose des fonctionnalités assez interessantes :
- privilege elevation ( http://deadly.org/article.php3?sid=20021017153959&mode=flat(...) )
plus besoin de programmes suid. C'est en cours de portage sur linux, mais c'est deja dasn openbsd 3.2, qui va sortir bientot.
- cryptage du swap ( http://www.openbsd.org/papers/swapencrypt.ps(...) )
-pile non executable ( http://www.deadly.org/article.php3?sid=20020724131711(...) )
il est probable que la plupart des ces fonctionnalités ( notamment la derniére ) existent sous linux.
mais, est ce qu'une distribution les propose par defaut ?
je ne parle pas d'une distrib confidentiel ( engarde linux, etc etc), mais d'une des 5 distribs les plus utilisés.
Pas a ma connaissance.
[^] # Re: Les Root Serveurs attaqués.
Posté par Misc (site web personnel) . En réponse à la dépêche Les Root Serveurs attaqués.. Évalué à 1.
http://www.wia.org/pub/rootserv.html(...)
on voit bien ou sont situes les machines.
si mes souvenirs sont bons, c des IBMs.
avant sun faisit la pub sur ca "nous sommes le point de .com", car ct des suns jusqu'a il y a deux ans.