Ça me gonfle qu'un gus prétend parler à ma place. Tu peux me citer, y a pas de problème. Mais inventer des propos et les "presque" signer matiasf est naze.
La Mandrake est tellement mieux que les autres, que linuxfr.org ne devrait plus parler des autres distributions.
Ben justement, parlons en.
RedHat qui bosse beaucoup sur gcc savait que gcc 2.96 n'allait jamais sortir. Il ont sorti un 2.96 qui est principalement un 3.0 avec compatibilité 2.95. RedHat a préféré 2.96 et non 3.0 et c'est tant mieux. Par contre ils auraient pu l'appeler 2.96rh pour éviter vos remarques lourdes maintenant. gcc 2.96 est sorti pour RH7.0 ! il y a eu 7.1, 7.2, 7.3, 8.0 et maintenant 9 et d'autres distributions l'on utilisé.
Mais voyons l'avis de gcc : http://gcc.gnu.org/gcc-2.96.html(...)
- "We would like to point out that GCC 2.96 is not a formal GCC release nor will there ever be such a release. Rather, GCC 2.96 has been the code- name for our development branch that will eventually become GCC 3.0."
=> Donc gcc-2.96 de RedHat est un 2.96 qui etait la branche de développement de gcc. La branche 2.96 n'allait pas être sortie par gcc. Pas d'ambiguïté.
Et comment devait nommer RedHat leur gcc ? 2.95 ou 3.0 ou rhgcc ?
Mais tant qu'il n'a pas essayé autre chose, tu ne peux pas conclure. Si il dit que ça chie sous Windows et avec un kernel vanilla, on peut envisager ta conclusion. Notes que je dis qu'il devrait essayer un autre noyau. Mais essayer une autre distribution, c'est pas stupide.
Concrêtement, ça veut dire que score de 4/30 peut te faire perder des XP.
En fonction de l'ensemble des votes de la semaine, un [-] peut être plus "agressif" qu'un [+].
J'ai installé une mdk 9.1 pour pas mourrir idiot. Lorsque je fesait un reboot depuis la mdk 9.1, il y a deux disque que le bios et Linux ne reconnaient plus. Si je fait un reset, c'est pareil. Je doit couper le courant.
Pour ton problème, essai avec un noyau officiel Marcelo. Surtout qu'il y a maintenant un rc du 2.4.21 :
http://www.fr.kernel.org/pub/linux/kernel/v2.4/testing/
Si tu ne sais pas compiler un noyau, il y a de l'aide ici :
http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/html/Kernel-HOWTO-html.tar.gz
> le déploiement de base de données (avec MySQL-64 )
Si c'est un OS 64 bits, c'est le minimum. De tout manière tout les gros projets logiciel libre sont 32/64 bits. Donc postgresql est aussi 64 bits sur un OS 64 bits (c'est le minimum).
> Unix n'est pas un système "sûr".
Considérer si Unix est un système "sûr" ou non, il faut regarder par domaine. Si je compare à mon auto-radio, Unix n'est pas sûr.
> Donc si c'est l'un des plus sûrs, c'est bien par défaut.
Tu veux dire que c'est "par hazard". Que le fait que chaque programme a sa mémoire virtuel, que les mots de passe sont cryptés, qu'il y a un système de protection de fichier, etc... n'avaient pas pour but de faire un système "sûr" ?
Je suis relativement d'accord pour dire qu'Unix n'est pas "sûr". Comme tous les OS a usage général. Et pour preuve que ce n'est pas sûr, il faut un admin pour "surveiller" la bécane, la mettre à jour. Mais sous-entendre que c'est la fruit du hazard...
> Je ne suis pas sûr qu'Unix soit un des OS les plus sûrs, ou alors par défaut de compétition.
Pas claire cette phrase.
Je prend une RedHat par exemple (je ne connais pas les autres). Je l'installes et je crées un compte utilisateur (j'ai pris soit de mettre un mot de passe au bios et à grub, j'ai un détecteur de métal pour que tu ne sortes pas le PC de la pièce, le boîtier est soudé pour que tu ne puisses pas le démonter). Tu fais quoi avec le compte utilisateur ? Il y a le "while(1) fock() ;" (faut paramétrer ulimit et c'est réglé), saturer le disque dur (il faut ajouter des quotas), limiter les performances en fesant des tonnes de requête sur les services disponibles (ça peut aussi être un moyen dérivé pour saturer le disque dur), bouffer de la mémoire vive, les descripteurs de fichiers etc (il y a encore ulimit pour limiter les dégats).
Les possibilités sont pas épaisses. Le mieux est de partir avec le disque dure sous le bras (si c'est possible) pour ajouter tranquillement chez toi un trou de sécurité, un sniffer. Après tu le réinstaller dans la bécane "ni vu ni connu", et tu attends que l'admin t'envoie le mot de passe root.
> les abus sont fréquents
Ouais mais il faut reconnaitre que c'est souvent sur des bécanes installés rapidement. Genre tu as le prompt lilo et tu peux booter en runlevel 1 ou avec "init=/bin/bash". Il n'y a pas de mot de passe sur le bios et tu peux booter sur une disquette. La bécane n'a pas été mise à jour depuis 3 ans, c'est très courrant même sous Unix/Linux, et il reste un énorme trou de sécurité (genre "ping -i 'eth0; chmod +s /bin/bash'" avec modprobe (c'est pas un problème d'overflow :-], c'est une erreur de conception), pas de /etc/shadow et un mot de passe qui se casse en 2 heures maximum, etc...).
Puis il y a tout les trucs classiques de l'admin qui fait un ftp ou rsh sur une bécane et sous le compte root (mot de passe en claire). Qui ne signe pas ces mails avec pgp et du coup tu peux usurper son identité pour demander le mot de passe root de la nouvelle becane, qui a un postit avec plein de mot de passe sur son bureau car il n'a pas de mémoire, qui tape au clavier à une lenteur effroyable et tu as tout le temps de noter le mot de passe root lorsqu'il se logue, qui téléphone à quelqu'un pour faire une manip urgente sous root et donne le mot de passe, qui une foi sur deux oublit de se délogguer lorsqu'il qu'il son bureau, etc...
C'est bien plus souvent un problème d'admin que d'OS et les mauvais exemples que j'ai donné je les ai vécu. La sécurité globale est égale au maillon le plus faible. Et c'est plus souvent l'admin que OS le maillon faible.
Je vais te donner un autre exemple "rigolo". J'étais dans une petite boîte, et je m'installe une RedHat 6.2 (ça doit être applicable à n'importe quelle distribution un minimum maintenu). A bout de quelques mois, ma bécane est très utilisée (c'était la seule bécane sous Linux), j'utilise bind, squid, ssh, apache/php, samba, mysql, posgresql. Tous les services sont accessibles de l'extérieur. Il y a deux admins qui s'amusent à sniffer ma bécane et détecte les services qui tournent et leur version. Fort de ce constat, il me chient un pendule et disant que certains services ne sont pas sûrs et que de tout de manière la RH est moins "secure" qu'une Debian. Donc il me demande de passer sous Debian. RedHat ou Debian, je me branle mais la raison donnée, c'est n'importe quoi. De plus ça allait me faire du boulot pour refaire la configuration. Je suis un peu énervé et je leur lance un défit. Je leur dit que je passe sous débian s'il me prouve qu'ils se sont introduit dans ma bécane (hors compte des autres utilisateurs) ou utilisé un exploit d'un service.
Ben, il ne s'est rien passé.
Les admins, c'est comme le reste, il y en a des bons et des ... moins bons. J'ai connu des admins très pointus, organisés et pragmatiques. Je ne mets pas tous les admins dans le même panier.
Non non, du pragmatisme.
S'il suffisait d'installer une bécane (2h), appliquer les mises à jour (1h), puis configurer (2h), faire deux scripts dans cron pour nettoyer les "conneries" des édutiants (qui bien que édutiants ont toutes les compétances pour craquer un système d'exploitation type Unix qui a pourtant une solide réputation de sécurité)(2h car il faut ajouter la pose café entre potes), les administrateurs seraient démystifiés.
Alors oui, pour que des étudiants compilent des programmes C++ (car les autres language ne posent pas de problème !?!) il faut le dernier cri de la technologie en terme de sécurité sinon tu es dans une merde noir.
> Donc pour toi, la recherche de plus de sécurité est inutile?
Rappel de mon post plus haut ( http://linuxfr.org/comments/197678,1.html(...) ) :
- "Je trouve bien que des gens bossent en avance sur la sécurité. Pour des serveurs critiques c'est toujours ça de pris. Mais de là à dire que "j'ai besoin" de trusted debian (ou équivalent)..."
> Si on te propose un patch qui améliore la sécurité de ton noyau, tu ne l'appliques pas parce que tu sais que tu es un bon admin?
C'est quoi ce propos ?
Je ne suis pas réfractaire à ce qui améliore la sécurité. Mais il faut faire des compromis (sécurité/fonctionnalité/performance/complexité) et se concentrer sur les fondamentaux.
Et dans les fondamentaux, il y a la supression des trous de sécurité. Ajouter un patch (de la complexite en plus et dont potentiellement des trous de sécurité en plus) n'est pas FORCÉMENT un gros avantage même si ça peut inhiber quelques cas de trou de sécurité. Car dans la pratique ça ne répond qu'à quelques cas bien peu nombreux de trou de sécurité (et encore faut-il qu'il y ait un trou de sécurité). Si ces patchs étaient "magnifiques", ils seraient depuis longtemps dans le noyau officiel.
Je ne remet pas en cause leur existance ! Mais pour en avoir BESOIN, il faut fournir un service très très très critique. Et avant que ces patchs soient significativement intéressants, il faut faire un grosse travail de configuration et d'audit de ton service (par exemple les scripts php développés pour ton service doivent être contrôlés. Il faut définir qui a autorité pour valider des modifications, mettre en place des tests d'attaque, mettre en place un gestionnaire de version pour revenir en arrière rapidement si une connerie est faite, bétonner les sauvegardes, proposer un mode dégradé mais bétonné côté sécurité (pas d'écriture, données confidentielles inaccessibles) lorsqu'un trou de sécurité est découvert, etc...).
J'ai simplement dit que l'emploi de ces patchs, extensions sont réservés à un ensemble de personne/organisme très restraint.
Si le programme suid root a un trou de sécurité et si les "extensions" de "trusted debian" permet d'éviter ce trou de sécurité (ce qui n'est pas garanti, voir par exemple ptrace et les bugs modprobe pour les plus gros problème, voir aussi le dernier problème sendmail qui est aussi un exploit local), c'est un plus. Mais il y a des si.
Je préfère m'appuier sur une distribe réactive sur les problèmes de sécurité et n'installer que des paquets signés. D'ailleur j'aimerais bien que rpm propose une options de configuration qui interdit par défaut l'installation de programmes dont la signature (pgp) n'a pas été validée.
J'aimerai aussi que l'on me trouve un page web avec quelques statistiques. Exemple :
- trou de sécurité pour 2002 : 50 dont 20 inhibés par l'extension bidule.
Hors j'ai rien vu jusqu'à maintenant qui montre que statistiquement c'est un avantage significatif.
> tu va bien en avoir dans le tas pour essaier un buffer overflow ou un truc comme ca.
Ben ça va être un exploit dans le compte de l'utilisateur. Au pire il peut faire un équivalent de "rm -rf /". Mais il n'a pas besoin de faire un exploit pour le faire, ni d'utilise gcc.
C'est un problème de configuration machine et ça demande un bon admin.
Si c'est un programme d'échange de programme entre utilisateur, gpg est plus indiqué pour ne lancer que les programmes des personnes "de confiance" (et à l'occasion connaitre celui qui t'a fait une crasse et, si l'envi te démange, de lui casser la gueule). C'est de la responsabilité des utilisateurs.
> c'est la que c'est utile, plus pour les exploits locaux que 'remote'
Ça ne change rien si tu as un serveur MySQL uniquement accessible en local par 200 utilisateurs, ce n'est pas plus critique que qu'un serveur MySQL accéssible à distance par 2000 personnes.
> tu as besoin de ca sur un serveur avec plein d'utilisateur avec acces shell
Pourquoi ? Tu as moins de chance de voir les fichiers de configuration modifiés avec ça ? Tu as moins de chance d'accéder aux mots de passes dans /etc/shadow ? Sans ça, tu peux "sniffer" le mot de passe root lorsque l'admin se loggue. Évidement, root ne doit pas se logguer sous X11 ou avec rsh, mais ça c'est un problème de configuration. Et si l'admin est bête au point de se logguer avec rsh, il faut avant tout changer d'admin et non de distribution.
Je connais les réponse...
> pour un pov serveur web ou de BDD un firewall / IDS font l'affaire.
Si ton serveur est un serveur web faut bien que le firewall laisse passer les requêtes http vers le serveur web. Donc le firewall ne protège pas ton serveur web. Ce serveur web, même "dernière" un firewall, doit être bien configuré et à jour.
Donc le firewall n'est pas LA solution. Si tu as un script php mal foutu, tu peux être dans la merde avec ou sans "Trusted Debian".
Je trouve bien que des gens bossent en avance sur la sécurité. Pour des serveurs critiques c'est toujours ça de pris. Mais de là à dire que "j'ai besoin" de trusted debian (ou équivalent)...
Mon sentiment est que pour un gros ou petit réseau, local ou non, ce n'est pas très utile.
J'ai regardé la démo. Il y a la pile, le tas, etc qui changent de place, mais il est possible de connaitre leur position (comme le montre la démo:-)). Ce n'est pas très utile.
Dans la démo, il donne un exemple concret où c'est un "plus". S'ils pouvaient donné plus exemple... Les trous de sécurité sur une année se comptent en dizaine.
Si c'était très utile, debian.org tournerait sous Trusted Debian. Je me demande s'il y a beaucoup de site (web, base de donnée, etc), même uniquement parmis les plus importants, qui utilisent ce niveau de "protection".
Puis il y a le problème du support. S'il y a un trou de sécurité dans le noyau (type ptrace) et qu'il faut attendre 2 semaines de plus car il y a moins de mainteneurs de la version spécialisée, ce n'est pas cool. Si ce noyau spécialité est moins utilisé, il est peut-être aussi moins audité.
> Si je ne veux pas de ces outils, je ne vois pas l'utilité d'installer la distrib et de les laisser inutilisés alors que je peux avoir une distrib qui ne les contient pas.
C'est ce qu j'ai dit plus haut :
- "Si tu n'as pas besoin des redhat-config* et kudzu, il est raisonnable d'installer une slack."
Pour info, j'utilise le chargement à la demande à une série de modprobe.
/etc/modules.conf :
# sauvegarde restaure le mixer
post-install snd-card-0 /usr/sbin/alsactl restore >/dev/null 2>&1 || :
pre-remove snd-card-0 /usr/sbin/alsactl store >/dev/null 2>&1 || :
# utilisation alsa (sinon c'est sound.o qui est chargé :-)).
alias char-major-116 snd
# le driver de la carte
alias snd-card-0 snd-ens1371
# les requête OSS sont dirigées vers les modules d'émulation alsa
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
Puis il suffit d'avoir :
/etc/rc.d/rc0.d/S01alsactl
/etc/rc.d/rc6.d/S01alsactl
pour sauvegarder le mixer sur halt ou reboot.
# Re: Coup de gueule
Posté par matiasf . En réponse au journal Coup de gueule. Évalué à -2.
La Mandrake est tellement mieux que les autres, que linuxfr.org ne devrait plus parler des autres distributions.
[^] # Re: Coup de gueule
Posté par matiasf . En réponse au journal Coup de gueule. Évalué à -3.
# Re: Mandrake 9.1
Posté par matiasf . En réponse au journal Mandrake 9.1. Évalué à -10.
# votez
Posté par matiasf . En réponse au journal Coup de gueule. Évalué à -10.
# Re: Noyaux 2.4.21 2.6 ...
Posté par matiasf . En réponse au journal Noyaux 2.4.21 2.6 .... Évalué à 3.
Il y a une rc. Comprend pas que l'on puisse poser une question pareille :
http://lwn.net/Articles/29596/(...)
> Le 2.6 arrive ?
What to expect :
http://www.codemonkey.org.uk/post-halloween-2.5.txt(...)
[^] # Re: kernel 2.4.21 !!!
Posté par matiasf . En réponse à la dépêche Conectiva Linux 9 est disponible. Évalué à 8.
RedHat qui bosse beaucoup sur gcc savait que gcc 2.96 n'allait jamais sortir. Il ont sorti un 2.96 qui est principalement un 3.0 avec compatibilité 2.95. RedHat a préféré 2.96 et non 3.0 et c'est tant mieux. Par contre ils auraient pu l'appeler 2.96rh pour éviter vos remarques lourdes maintenant. gcc 2.96 est sorti pour RH7.0 ! il y a eu 7.1, 7.2, 7.3, 8.0 et maintenant 9 et d'autres distributions l'on utilisé.
Mais voyons l'avis de gcc :
http://gcc.gnu.org/gcc-2.96.html(...)
- "We would like to point out that GCC 2.96 is not a formal GCC release nor will there ever be such a release. Rather, GCC 2.96 has been the code- name for our development branch that will eventually become GCC 3.0."
=> Donc gcc-2.96 de RedHat est un 2.96 qui etait la branche de développement de gcc. La branche 2.96 n'allait pas être sortie par gcc. Pas d'ambiguïté.
Et comment devait nommer RedHat leur gcc ? 2.95 ou 3.0 ou rhgcc ?
Pour info voici l'avis de RedHat :
http://www.redhat.com/advice/speaks_gcc.html(...)
Il n'y a rien en contradiction avec les propos de gcc plus haut.
[^] # Re: kernel 2.4.21 !!!
Posté par matiasf . En réponse à la dépêche Conectiva Linux 9 est disponible. Évalué à 1.
[^] # Re: kernel 2.4.21 !!!
Posté par matiasf . En réponse à la dépêche Conectiva Linux 9 est disponible. Évalué à 4.
Dès que Linux 2.4.21 va sortir, les distributions avec un 2.4.22 vont fleurir.
[^] # Re: plantage machine.....
Posté par matiasf . En réponse au journal plantage machine...... Évalué à 2.
Mais tant qu'il n'a pas essayé autre chose, tu ne peux pas conclure. Si il dit que ça chie sous Windows et avec un kernel vanilla, on peut envisager ta conclusion. Notes que je dis qu'il devrait essayer un autre noyau. Mais essayer une autre distribution, c'est pas stupide.
[^] # Re: Nouveaux utilisateurs
Posté par matiasf . En réponse au journal Nouveaux utilisateurs. Évalué à 4.
En fonction de l'ensemble des votes de la semaine, un [-] peut être plus "agressif" qu'un [+].
# Re: Linux (x86) et les Mac
Posté par matiasf . En réponse au journal Linux (x86) et les Mac. Évalué à 3.
Mes 2 centimes d'.
# Re: plantage machine.....
Posté par matiasf . En réponse au journal plantage machine...... Évalué à 1.
# Re: Mandrake Linux Corporate Server 2.1 pour processeur AMD OpteronTM est maintenant disponible
Posté par matiasf . En réponse à la dépêche Mandrake Linux Corporate Server 2.1 pour processeur AMD OpteronTM est maintenant disponible. Évalué à 1.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . En réponse à la dépêche Trusted Debian 1.0. Évalué à 1.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . En réponse à la dépêche Trusted Debian 1.0. Évalué à 5.
Pas claire cette phrase.
Je prend une RedHat par exemple (je ne connais pas les autres). Je l'installes et je crées un compte utilisateur (j'ai pris soit de mettre un mot de passe au bios et à grub, j'ai un détecteur de métal pour que tu ne sortes pas le PC de la pièce, le boîtier est soudé pour que tu ne puisses pas le démonter). Tu fais quoi avec le compte utilisateur ? Il y a le "while(1) fock() ;" (faut paramétrer ulimit et c'est réglé), saturer le disque dur (il faut ajouter des quotas), limiter les performances en fesant des tonnes de requête sur les services disponibles (ça peut aussi être un moyen dérivé pour saturer le disque dur), bouffer de la mémoire vive, les descripteurs de fichiers etc (il y a encore ulimit pour limiter les dégats).
Les possibilités sont pas épaisses. Le mieux est de partir avec le disque dure sous le bras (si c'est possible) pour ajouter tranquillement chez toi un trou de sécurité, un sniffer. Après tu le réinstaller dans la bécane "ni vu ni connu", et tu attends que l'admin t'envoie le mot de passe root.
> les abus sont fréquents
Ouais mais il faut reconnaitre que c'est souvent sur des bécanes installés rapidement. Genre tu as le prompt lilo et tu peux booter en runlevel 1 ou avec "init=/bin/bash". Il n'y a pas de mot de passe sur le bios et tu peux booter sur une disquette. La bécane n'a pas été mise à jour depuis 3 ans, c'est très courrant même sous Unix/Linux, et il reste un énorme trou de sécurité (genre "ping -i 'eth0; chmod +s /bin/bash'" avec modprobe (c'est pas un problème d'overflow :-], c'est une erreur de conception), pas de /etc/shadow et un mot de passe qui se casse en 2 heures maximum, etc...).
Puis il y a tout les trucs classiques de l'admin qui fait un ftp ou rsh sur une bécane et sous le compte root (mot de passe en claire). Qui ne signe pas ces mails avec pgp et du coup tu peux usurper son identité pour demander le mot de passe root de la nouvelle becane, qui a un postit avec plein de mot de passe sur son bureau car il n'a pas de mémoire, qui tape au clavier à une lenteur effroyable et tu as tout le temps de noter le mot de passe root lorsqu'il se logue, qui téléphone à quelqu'un pour faire une manip urgente sous root et donne le mot de passe, qui une foi sur deux oublit de se délogguer lorsqu'il qu'il son bureau, etc...
C'est bien plus souvent un problème d'admin que d'OS et les mauvais exemples que j'ai donné je les ai vécu. La sécurité globale est égale au maillon le plus faible. Et c'est plus souvent l'admin que OS le maillon faible.
Je vais te donner un autre exemple "rigolo". J'étais dans une petite boîte, et je m'installe une RedHat 6.2 (ça doit être applicable à n'importe quelle distribution un minimum maintenu). A bout de quelques mois, ma bécane est très utilisée (c'était la seule bécane sous Linux), j'utilise bind, squid, ssh, apache/php, samba, mysql, posgresql. Tous les services sont accessibles de l'extérieur. Il y a deux admins qui s'amusent à sniffer ma bécane et détecte les services qui tournent et leur version. Fort de ce constat, il me chient un pendule et disant que certains services ne sont pas sûrs et que de tout de manière la RH est moins "secure" qu'une Debian. Donc il me demande de passer sous Debian. RedHat ou Debian, je me branle mais la raison donnée, c'est n'importe quoi. De plus ça allait me faire du boulot pour refaire la configuration. Je suis un peu énervé et je leur lance un défit. Je leur dit que je passe sous débian s'il me prouve qu'ils se sont introduit dans ma bécane (hors compte des autres utilisateurs) ou utilisé un exploit d'un service.
Ben, il ne s'est rien passé.
Les admins, c'est comme le reste, il y en a des bons et des ... moins bons. J'ai connu des admins très pointus, organisés et pragmatiques. Je ne mets pas tous les admins dans le même panier.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . En réponse à la dépêche Trusted Debian 1.0. Évalué à 3.
Non non, du pragmatisme.
S'il suffisait d'installer une bécane (2h), appliquer les mises à jour (1h), puis configurer (2h), faire deux scripts dans cron pour nettoyer les "conneries" des édutiants (qui bien que édutiants ont toutes les compétances pour craquer un système d'exploitation type Unix qui a pourtant une solide réputation de sécurité)(2h car il faut ajouter la pose café entre potes), les administrateurs seraient démystifiés.
Alors oui, pour que des étudiants compilent des programmes C++ (car les autres language ne posent pas de problème !?!) il faut le dernier cri de la technologie en terme de sécurité sinon tu es dans une merde noir.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . En réponse à la dépêche Trusted Debian 1.0. Évalué à -1.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . En réponse à la dépêche Trusted Debian 1.0. Évalué à 6.
Rappel de mon post plus haut ( http://linuxfr.org/comments/197678,1.html(...) ) :
- "Je trouve bien que des gens bossent en avance sur la sécurité. Pour des serveurs critiques c'est toujours ça de pris. Mais de là à dire que "j'ai besoin" de trusted debian (ou équivalent)..."
> Si on te propose un patch qui améliore la sécurité de ton noyau, tu ne l'appliques pas parce que tu sais que tu es un bon admin?
C'est quoi ce propos ?
Je ne suis pas réfractaire à ce qui améliore la sécurité. Mais il faut faire des compromis (sécurité/fonctionnalité/performance/complexité) et se concentrer sur les fondamentaux.
Et dans les fondamentaux, il y a la supression des trous de sécurité. Ajouter un patch (de la complexite en plus et dont potentiellement des trous de sécurité en plus) n'est pas FORCÉMENT un gros avantage même si ça peut inhiber quelques cas de trou de sécurité. Car dans la pratique ça ne répond qu'à quelques cas bien peu nombreux de trou de sécurité (et encore faut-il qu'il y ait un trou de sécurité). Si ces patchs étaient "magnifiques", ils seraient depuis longtemps dans le noyau officiel.
Je ne remet pas en cause leur existance ! Mais pour en avoir BESOIN, il faut fournir un service très très très critique. Et avant que ces patchs soient significativement intéressants, il faut faire un grosse travail de configuration et d'audit de ton service (par exemple les scripts php développés pour ton service doivent être contrôlés. Il faut définir qui a autorité pour valider des modifications, mettre en place des tests d'attaque, mettre en place un gestionnaire de version pour revenir en arrière rapidement si une connerie est faite, bétonner les sauvegardes, proposer un mode dégradé mais bétonné côté sécurité (pas d'écriture, données confidentielles inaccessibles) lorsqu'un trou de sécurité est découvert, etc...).
J'ai simplement dit que l'emploi de ces patchs, extensions sont réservés à un ensemble de personne/organisme très restraint.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . En réponse à la dépêche Trusted Debian 1.0. Évalué à 1.
Si le programme suid root a un trou de sécurité et si les "extensions" de "trusted debian" permet d'éviter ce trou de sécurité (ce qui n'est pas garanti, voir par exemple ptrace et les bugs modprobe pour les plus gros problème, voir aussi le dernier problème sendmail qui est aussi un exploit local), c'est un plus. Mais il y a des si.
Je préfère m'appuier sur une distribe réactive sur les problèmes de sécurité et n'installer que des paquets signés. D'ailleur j'aimerais bien que rpm propose une options de configuration qui interdit par défaut l'installation de programmes dont la signature (pgp) n'a pas été validée.
J'aimerai aussi que l'on me trouve un page web avec quelques statistiques. Exemple :
- trou de sécurité pour 2002 : 50 dont 20 inhibés par l'extension bidule.
Hors j'ai rien vu jusqu'à maintenant qui montre que statistiquement c'est un avantage significatif.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . En réponse à la dépêche Trusted Debian 1.0. Évalué à 3.
Ben ça va être un exploit dans le compte de l'utilisateur. Au pire il peut faire un équivalent de "rm -rf /". Mais il n'a pas besoin de faire un exploit pour le faire, ni d'utilise gcc.
C'est un problème de configuration machine et ça demande un bon admin.
Si c'est un programme d'échange de programme entre utilisateur, gpg est plus indiqué pour ne lancer que les programmes des personnes "de confiance" (et à l'occasion connaitre celui qui t'a fait une crasse et, si l'envi te démange, de lui casser la gueule). C'est de la responsabilité des utilisateurs.
> c'est la que c'est utile, plus pour les exploits locaux que 'remote'
Ça ne change rien si tu as un serveur MySQL uniquement accessible en local par 200 utilisateurs, ce n'est pas plus critique que qu'un serveur MySQL accéssible à distance par 2000 personnes.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . En réponse à la dépêche Trusted Debian 1.0. Évalué à 4.
Pourquoi ? Tu as moins de chance de voir les fichiers de configuration modifiés avec ça ? Tu as moins de chance d'accéder aux mots de passes dans /etc/shadow ? Sans ça, tu peux "sniffer" le mot de passe root lorsque l'admin se loggue. Évidement, root ne doit pas se logguer sous X11 ou avec rsh, mais ça c'est un problème de configuration. Et si l'admin est bête au point de se logguer avec rsh, il faut avant tout changer d'admin et non de distribution.
Je connais les réponse...
> pour un pov serveur web ou de BDD un firewall / IDS font l'affaire.
Si ton serveur est un serveur web faut bien que le firewall laisse passer les requêtes http vers le serveur web. Donc le firewall ne protège pas ton serveur web. Ce serveur web, même "dernière" un firewall, doit être bien configuré et à jour.
Donc le firewall n'est pas LA solution. Si tu as un script php mal foutu, tu peux être dans la merde avec ou sans "Trusted Debian".
Je trouve bien que des gens bossent en avance sur la sécurité. Pour des serveurs critiques c'est toujours ça de pris. Mais de là à dire que "j'ai besoin" de trusted debian (ou équivalent)...
[^] # Re: Trusted Debian 1.0
Posté par matiasf . En réponse à la dépêche Trusted Debian 1.0. Évalué à 6.
J'ai regardé la démo. Il y a la pile, le tas, etc qui changent de place, mais il est possible de connaitre leur position (comme le montre la démo:-)). Ce n'est pas très utile.
Dans la démo, il donne un exemple concret où c'est un "plus". S'ils pouvaient donné plus exemple... Les trous de sécurité sur une année se comptent en dizaine.
Si c'était très utile, debian.org tournerait sous Trusted Debian. Je me demande s'il y a beaucoup de site (web, base de donnée, etc), même uniquement parmis les plus importants, qui utilisent ce niveau de "protection".
Puis il y a le problème du support. S'il y a un trou de sécurité dans le noyau (type ptrace) et qu'il faut attendre 2 semaines de plus car il y a moins de mainteneurs de la version spécialisée, ce n'est pas cool. Si ce noyau spécialité est moins utilisé, il est peut-être aussi moins audité.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par matiasf . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 0.
C'est ce qu j'ai dit plus haut :
- "Si tu n'as pas besoin des redhat-config* et kudzu, il est raisonnable d'installer une slack."
> compris cette fois ci ?
Ben là tu ne trolles pas sur rpm, ça me va.
# Re: Glade 2.0.0 est disponible
Posté par matiasf . En réponse à la dépêche Glade 2.0.0 est disponible. Évalué à 1.
$ rpm -q --whatrequires libglade.so.0 libglade-2.0.so.0 | wc
44 44 853
$
Dont notablement evolution, gnucash, gnumeric, anjuta, nautilus.
[^] # Re: Un test négatif (non constructif) de la Mandrake 9.1
Posté par matiasf . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 4.
/etc/modules.conf :
# sauvegarde restaure le mixer
post-install snd-card-0 /usr/sbin/alsactl restore >/dev/null 2>&1 || :
pre-remove snd-card-0 /usr/sbin/alsactl store >/dev/null 2>&1 || :
# utilisation alsa (sinon c'est sound.o qui est chargé :-)).
alias char-major-116 snd
# le driver de la carte
alias snd-card-0 snd-ens1371
# les requête OSS sont dirigées vers les modules d'émulation alsa
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
Puis il suffit d'avoir :
/etc/rc.d/rc0.d/S01alsactl
/etc/rc.d/rc6.d/S01alsactl
pour sauvegarder le mixer sur halt ou reboot.