Mais bien sûr, le noyau d'OpenBSD est le seul à être audité en continu...
J'ai jamais dit ca.
Mais bon c 'est pas grave, c'est la maniére habituel de discrediter quelqu'un, non ?
Cela dit, GNU n'a jamais prétendu comme certains que ses outils sont parfaitement sûrs.
En effet, c'est toi qui l'a dit :
Les logiciels de base et la libc d'OpenBSD ne sont pas plus sécurisés que les outils GNU.
ce qui dit autrement, les logiciels d'openbsd sont aussi securisés, ou moins sécurisés que ceux de gnu.
, ou encore, les outils GNU sont aussi securisés ou plus que ceux d'OPenBSD.
En equation :
soit S_o la securite des outils openbsd.
Soit S_g celle des outils GNU.
tu dit :
! ( S_o > S_g )
<=> ( S_o <= S_g )
<=> ( S_g >= S_o )
Si on part du principe que la communauté de la sécurité reconnait openbsd comme etant un des systems les plus secure du monde ( car c'est aps le plus sur, il y en a qui ont un niveau superieur ( Trusted XENIX, niveau B2, le plus haut actuellement ) ), alors, tu affirme que GNU a les outils parmi les plus secure.
Je ne nie pas que les outils GNU sont bons., comme je l'ai dit, et effectivement, il n'y pas de trous de securités majeurs intrinseque.
Mais de la a dire que les outils GNU et toutes leurs options sont les plus surs du monde, il y a un pas que je te laisse franchir seul....
pour te donner un exemple, tiré d'un poly de Mr Probst, mon prof de sécurite :
--------
The ftp/GNU tar hole
____________________
In fancy systems, 'ftpd' will allow a client to run 'tar' on the 'ftp'
server (the remote host). Ah, but people started using feature-rich GNU tar.
This allows:
quote site exec tar -c -v --rsh-command=<arbitrarycommand> -f <host>:
<filename> <filename>
Moral: new features mean new interactions.
------
conclusion, parfois le systeme devient si complexe qu on ne peut pas le maitriser de bout en bout.
quand OpenBSD parle d'audit continu, ca comprends ca.
Mais bon, pour ma part, je prefere linux qu'un os comme openbsd ou on peut en faire un peu moins en echange d'une securité plus poussé.
ils sont très rapidement corrigés en cas de problèmes
a parce que openbsd, ils laisse trainer ?
toutes les bons os sortent des correctifs rapidement.
et openbsd fait pas exception.
mais j'imagine que tu as un exemple precis a donner....
pour un gain en sécurité nul.
Va demander a hebergement-gratuit.com ce qu'il pense d'openbsd...
enfin, je pense qu'on peut faire confiance a un type comme toi, qui a un boulot tellement important que tu passes ton temps a poster sur linuxfr, sans donner ton vrai nom, tellement tu as un boulot important que tu doit proteger.
J'imagine de plus que tu as du deja essayer openbsd pour donner un avis si net et si parfait.
Ça fait 2 vulnérabilités locales en 5 ans pour le noyau Linux.
Si il n'y avait que 2 races conditions dans tout le noyau Linux en 5 ans, je dit bravo.
Il a jamais du avoir de crash sur les machines SMP....
Regarde le premier lien, il y a marqué "multiple security problems".
C'est sur, si tu compte en terme de mise à jour, alors, oui, il y a eu deux mises à jours dans la debian ( qui , c'est connu, a utilisée tout les noyaux Linux sortis depuis 5 ans ).
Si tu compte en termes de vulnérabilités, je pense que 2 "write into kernel memory" et un "give a local user extra privileges" , ca fait 3.
Plus un, si on compte l'autre advisorie, ben voila, le compte est bon.
3 + 1 = 4.
J'ai pas de changelog sous la main, mais, en guise d'exercice, je te laisse regarder le nombre d'occurence du mot 'Race' dans les changelog du noyau depuis 2 ans.
J'ai compté 7 dans le changelog du 2.4.19.
Bien sur, ca ne veut pas dire que c'est exploitable, loin de la.
Mais bon, considérer que une personne , en regardant le noyau, fasse mieux que 5 ans d'audit continue , par toute une equipe, c'est un peu utopique...
Et ca ne change rien au fait que personne ( meme pas Andreas Schuldei ) n'a montré la liste exacte de ses si nombreuses races conditions dans le noyau OpenBSD.
Enfin, hier, en regardant sur les archives, il n'a rien montré.
Peut etre qu'elles sont si nombreuses qu'il n'a pas assez de bande passante pour nous en donner une liste ?
HA, HA, HA.
Pardon.
Y a pas de quoi, je comprends que ce soit dur de continuer a dire les utilitaires GNU sont tous completement securisés, alors que je sort le contraire.
Mais, je tiens a préciser que je pense que cette faille est ridicule, et que ca change rien au fait que Gnu Tar a plus de fonctionnalités que celui d'openbsd.
Enfin, c'est dur de de rebondir face un argument aussi construit et étayé...
Si tu n'es pas capable de comprendre les intérêts, particulièrement en termes de sécurité, d'avoir une gestion convenable des bibliothèques partagées, je pense que tu devrais arrêter de débattre de sécurité.
Personnellement, je pense que tu devrait arreter de debattre tout court tant que tu ne pensera pas a lire ce que l'autre t'a écrit.
OpenBSD supporte les bibliothéques, au format ELF.
Récupere la libvorbis, et regarde le fichier .so.
De plus, si tu estime que la gestion des bibliothéques a.out sous OpenBSD est nulle en matiére de sécurité, va leur expliquer.
Je suis sur qu'ils ont completement oubliés ce point si élementaire.
Faut dire qu'ils se concentrent surtout sur le multimédia....
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.
J'ai jamais dit ca.
Mais bon c 'est pas grave, c'est la maniére habituel de discrediter quelqu'un, non ?
Cela dit, GNU n'a jamais prétendu comme certains que ses outils sont parfaitement sûrs.
En effet, c'est toi qui l'a dit :
Les logiciels de base et la libc d'OpenBSD ne sont pas plus sécurisés que les outils GNU.
ce qui dit autrement, les logiciels d'openbsd sont aussi securisés, ou moins sécurisés que ceux de gnu.
, ou encore, les outils GNU sont aussi securisés ou plus que ceux d'OPenBSD.
En equation :
soit S_o la securite des outils openbsd.
Soit S_g celle des outils GNU.
tu dit :
! ( S_o > S_g )
<=> ( S_o <= S_g )
<=> ( S_g >= S_o )
Si on part du principe que la communauté de la sécurité reconnait openbsd comme etant un des systems les plus secure du monde ( car c'est aps le plus sur, il y en a qui ont un niveau superieur ( Trusted XENIX, niveau B2, le plus haut actuellement ) ), alors, tu affirme que GNU a les outils parmi les plus secure.
Je ne nie pas que les outils GNU sont bons., comme je l'ai dit, et effectivement, il n'y pas de trous de securités majeurs intrinseque.
Mais de la a dire que les outils GNU et toutes leurs options sont les plus surs du monde, il y a un pas que je te laisse franchir seul....
pour te donner un exemple, tiré d'un poly de Mr Probst, mon prof de sécurite :
--------
The ftp/GNU tar hole
____________________
In fancy systems, 'ftpd' will allow a client to run 'tar' on the 'ftp'
server (the remote host). Ah, but people started using feature-rich GNU tar.
This allows:
quote site exec tar -c -v --rsh-command=<arbitrarycommand> -f <host>:
<filename> <filename>
Moral: new features mean new interactions.
------
conclusion, parfois le systeme devient si complexe qu on ne peut pas le maitriser de bout en bout.
quand OpenBSD parle d'audit continu, ca comprends ca.
Mais bon, pour ma part, je prefere linux qu'un os comme openbsd ou on peut en faire un peu moins en echange d'une securité plus poussé.
ils sont très rapidement corrigés en cas de problèmes
a parce que openbsd, ils laisse trainer ?
toutes les bons os sortent des correctifs rapidement.
et openbsd fait pas exception.
mais j'imagine que tu as un exemple precis a donner....
pour un gain en sécurité nul.
Va demander a hebergement-gratuit.com ce qu'il pense d'openbsd...
enfin, je pense qu'on peut faire confiance a un type comme toi, qui a un boulot tellement important que tu passes ton temps a poster sur linuxfr, sans donner ton vrai nom, tellement tu as un boulot important que tu doit proteger.
J'imagine de plus que tu as du deja essayer openbsd pour donner un avis si net et si parfait.
[^] # 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.
Si il n'y avait que 2 races conditions dans tout le noyau Linux en 5 ans, je dit bravo.
Il a jamais du avoir de crash sur les machines SMP....
Regarde le premier lien, il y a marqué "multiple security problems".
C'est sur, si tu compte en terme de mise à jour, alors, oui, il y a eu deux mises à jours dans la debian ( qui , c'est connu, a utilisée tout les noyaux Linux sortis depuis 5 ans ).
Si tu compte en termes de vulnérabilités, je pense que 2 "write into kernel memory" et un "give a local user extra privileges" , ca fait 3.
Plus un, si on compte l'autre advisorie, ben voila, le compte est bon.
3 + 1 = 4.
J'ai pas de changelog sous la main, mais, en guise d'exercice, je te laisse regarder le nombre d'occurence du mot 'Race' dans les changelog du noyau depuis 2 ans.
J'ai compté 7 dans le changelog du 2.4.19.
Bien sur, ca ne veut pas dire que c'est exploitable, loin de la.
Mais bon, considérer que une personne , en regardant le noyau, fasse mieux que 5 ans d'audit continue , par toute une equipe, c'est un peu utopique...
Et ca ne change rien au fait que personne ( meme pas Andreas Schuldei ) n'a montré la liste exacte de ses si nombreuses races conditions dans le noyau OpenBSD.
Enfin, hier, en regardant sur les archives, il n'a rien montré.
Peut etre qu'elles sont si nombreuses qu'il n'a pas assez de bande passante pour nous en donner une liste ?
HA, HA, HA.
Pardon.
Y a pas de quoi, je comprends que ce soit dur de continuer a dire les utilitaires GNU sont tous completement securisés, alors que je sort le contraire.
Mais, je tiens a préciser que je pense que cette faille est ridicule, et que ca change rien au fait que Gnu Tar a plus de fonctionnalités que celui d'openbsd.
Enfin, c'est dur de de rebondir face un argument aussi construit et étayé...
Si tu n'es pas capable de comprendre les intérêts, particulièrement en termes de sécurité, d'avoir une gestion convenable des bibliothèques partagées, je pense que tu devrais arrêter de débattre de sécurité.
Personnellement, je pense que tu devrait arreter de debattre tout court tant que tu ne pensera pas a lire ce que l'autre t'a écrit.
OpenBSD supporte les bibliothéques, au format ELF.
Récupere la libvorbis, et regarde le fichier .so.
De plus, si tu estime que la gestion des bibliothéques a.out sous OpenBSD est nulle en matiére de sécurité, va leur expliquer.
Je suis sur qu'ils ont completement oubliés ce point si élementaire.
Faut dire qu'ils se concentrent surtout sur le multimédia....
[^] # 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.