Elle inclut un grand nombre de patchs noyau (PaX, propriétés anti-buffer overflow, pile non exécutable, propriétés aléatoires) et de fonctionnalités spécifiques: FreeS/wan, RSBAC (contrôle d'accès), GCC modifié...
La Trusted Debian est disponible sous forme d'une source supplémentaire pour APT qui vient remplacer les paquets officiels debian (elle n'est pour l'instant pas installable directement, se servir d'une Woody fraîchement installée puis indiquer les sources TrustedDebian)
Aller plus loin
- Trusted Debian (8 clics)
- L'annonce (1 clic)
- La FAQ (2 clics)
- Les miroirs (3 clics)
- Une "démonstration" (3 clics)
# Re: Trusted Debian 1.0
Posté par Anonyme . Évalué à 10.
Ceci dit, pourquoi ce travail ne serait-il pas intégré à la version par défaut ? Ca ne ferait pas de mal d'avoir toutes ces bonnes choses, ceux qui les veulent s'en servent, et ca reste dispo pour tous ceux qui voudraient utiliser IPsec ou autres plus tard...
# Re: Trusted Debian 1.0
Posté par earxtacy . Évalué à 10.
http://www.trusteddebian.org/demo.html(...)
ces fonctionnalités sont celles qui commencent à être installé sur openbsd aussi, parfois de maniere un peu differente.
# Re: Trusted Debian 1.0
Posté par gnumdk (site web personnel) . Évalué à 5.
[^] # Re: Trusted Debian 1.0
Posté par Anonyme . Évalué à 2.
Si c'est dispo et que ça ne coute pas, pourquoi pas - bien sur. Mais à mon avis ces paquets préparés spécialement pour la sécurité doivent être surtout utile sur les machines qui sont très exposées... Les serveurs sur internet, qui à la différence d'un serveur sur un réseau local ne peuvent se permettre de tout envoyer balader par défaut. Les serveurs sur les réseaux d'administrations, d'entreprise, qui ont des utilisateurs aux intentions hostiles.
Pour ton installation, il n'y a pas de « fou rire » à choisir une distrib plutôt qu'une autre. Il n'y pas une solution faite que d'avantages et une solution faite que d'inconvenient. C'est à toi de voir.
[^] # Re: Trusted Debian 1.0
Posté par earxtacy . Évalué à 1.
a moins que tu sois seule sur ton reseau.
[^] # Re: Trusted Debian 1.0
Posté par Anonyme . Évalué à 2.
A priori, sur un réseau qui concerne 10 personnes ou moins qui se connaissent, les risques d'attaque de l'intérieur sont très limitées. Et si j'ai bien suivi, gnumdk parle de ce type de réseau.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . É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: Trusted Debian 1.0
Posté par vrm (site web personnel) . Évalué à 0.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . É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 vrm (site web personnel) . Évalué à 9.
tu va bien en avoir dans le tas pour essaier un buffer overflow ou un truc comme ca.
c'est la que c'est utile, plus pour les exploits locaux que 'remote'
et puis tu l'installe si tu en as le besoin, c'est pour ca que c'est une option sur woody
[^] # Re: Trusted Debian 1.0
Posté par matiasf . É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 Cédric Foll . Évalué à 6.
Non, il va faire ça sur un prog suid root.
Et le type se retrouve root sur la machine.
C'est donc en effet utile sur un serveur avec beaucoup de comptes de pouvoir eviter les buffer overflow.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . É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 jeanmarc . Évalué à 7.
J'ai l'impression que tu te bas contre des moulins à vent là.
Les méchants misent sur tes "si" et tes négligences.
Concernant leur manque de réactivité, leur travail s'effectue surtout au niveau du noyau et de quelques patchs spécifiquent. De ce fait, les audits de code s'additionnent et profitent à tous.
[^] # Re: Trusted Debian 1.0
Posté par Éric (site web personnel) . Évalué à 9.
Ca fait tout de meme longtemps qu'on entend parler des patchs pourune pile non exécutable. Je me dis (betement ?) que si c'etait si simple ca serait par défaut partout depuis longtemps.
reste à savoir où j'ai fait une erreur dans mon raisonnement
[^] # Re: Trusted Debian 1.0
Posté par Linux_GTI . Évalué à 8.
- "Trusted Palladium Debian"
et ça va marcher...
[^] # Re: Trusted Debian 1.0
Posté par vrm (site web personnel) . Évalué à 5.
si tu utilise ton PC comme outil bureatique ou dans un cluster de calcul tu preferrera les perfs
[^] # Re: Trusted Debian 1.0
Posté par Moby-Dik . Évalué à -2.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . É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 vrm (site web personnel) . Évalué à -2.
C'est un problème de configuration machine et ça demande un bon admin.
Je vois tu n'y comprend rien en fait :)
[^] # Re: Trusted Debian 1.0
Posté par matiasf . Évalué à -1.
[^] # Re: Trusted Debian 1.0
Posté par ludotux . Évalué à 4.
c'est la que c'est utile
Et comment tu fais actuellement ?
Tu réinstalles le système toutes les semaines ?
Et comment a fait Unix pour faire parti des OS les plus sûrs sans ces "goodies" ?
Je trouve qu'il y a beaucoup de frime dans cette course à l'armement qui n'est pas argumentée.
Je n'ai pas envis de me faire chier avec des trucs qui font passer le niveau de sécurité de mon système de 97 à 98 sachant que dès que je fais une connerie de configuration, il peut chuter à 20.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . É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 Moby-Dik . Évalué à 3.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . É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 Moby-Dik . Évalué à 3.
Je passe en revue tous les trous de sécu existants sur les softs et bibliothèques installés, y compris les services réseau que je peux interroger. Enfin, pas moi, vu que je ne suis pas un cracker.
Quand on voit le nombre de trous qu'il y a par an sur les outils traditionnellement livrés avec les différents Unix (voire dans les noyaux des Unix eux-mêmes, comme le noyau Linux, ou dans les bibliothèques les plus fondamentales comme la glibc), Unix n'est pas un système "sûr". Donc si c'est l'un des plus sûrs, c'est bien par défaut.
[^] # Re: Trusted Debian 1.0
Posté par matiasf . Évalué à 1.
[^] # Re: Trusted Debian 1.0
Posté par Anonyme . Évalué à 3.
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". »
Concrêtement, le firewall ne fait pas forcement du tout ou rien. C'est à dire que même en laissant passer les requêtes, il peut toujours avoir un rôle (interdire certain types de requêtes, car toutes ne sont légitimes... ).
Donc le firewall protège le serveur web, en partie.
Bien entendu, si t'as un script php qui est une faille de sécurité, ça peut poser problème. Par exemple, si ton script php devoile le contenu de /etc/shadow, ça peut poser problème, si quelqu'un trouve le moyen d'avoir un shell sur cette machine (effectivement, craignos si le ssh est ouvert et qu'il accepte les mots de passe.
Mais ce problème là est toujours vrai. Si t'as un programme en C (qui ne passe pas par le serveur web) qui donne le contenu de shadow... Mais à ce niveau là, n'est-ce pas le système qui est mal configuré ? (www-data ne peut pas lire /etc/shadow en théorie).
[^] # Re: Trusted Debian 1.0
Posté par Cédric Foll . Évalué à 10.
cf www.nessus.org
La aussi tu as juste à cliquer sur le bouton ok (j'exagère à peine) et tu te retrouves avec une grosse baterie de tests et un rapport de vulnérabilités.
# Re: Trusted Debian 1.0
Posté par Olivier . Évalué à 10.
http://www.openwall.com/Owl/(...)
OpenWall est basé sur RedHat mais est une distribution orientée vers la sécurité avec aussi une gestion des buffer overflow par exemple.
Peut-être (si ça n'existe pas déjà) qu'il serait bon d'avoir une page quelque part qui reprendrait les distributions Linux (je sais qu'il y en a énormément) classée par catégorie selon leur fonction première (peut-être suis-je utopiste).
[^] # Re: Trusted Debian 1.0
Posté par koxinga . Évalué à 4.
[^] # Re: Trusted Debian 1.0
Posté par deresh . Évalué à 4.
http://www.linux.org/dist/list.html(...)
openwall. j'ai fait quelleques jours dessus. Je ne conteste pas la qualité, je n'ai pas eu le temps de me faire un avis, mais, si je ne me trompe pas, elle utilise un kernel 2.2 (2.2.25-ow1 me dit leur "Change logs"): iptables..., tous les drivers ne compilent pas (mon modem ne marche pas).
En plus, leur site internet et en .com; Trusted Debian lui en .org (bien sûr)
[^] # Re: Trusted Debian 1.0
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
On recoit les deux listes Language et Category mais pas la fin du formulaire (ni de la page...) donc on peut pas acceder à la liste...
[^] # Re: Trusted Debian 1.0
Posté par deresh . Évalué à 3.
[^] # Re: Trusted Debian 1.0
Posté par Anonyme . Évalué à 3.
Ca change quelque chose, fondamentalement ?
[^] # Re: Trusted Debian 1.0
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: Trusted Debian 1.0
Posté par deresh . Évalué à 4.
mais mes premiéres motivations pour lacher windows etait des trucs de ce genre
Afin de ménager les succeptibilités, je corrige:
leur site internet et en .com; Trusted Debian lui en .org (bien sûr)
devien
leur site internet et en .com; Trusted Debian lui en .org (bien sûr) :~)
# Re: Trusted Debian 1.0
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
Merci à sam qui osait pas la poster :-)
[^] # tcpa sa sux
Posté par Anonyme . Évalué à -10.
Debian étant une version libre et kimarche de la mandrake, tu devrais avoir la réponse... ;)
[^] # Re: tcpa sa sux
Posté par Nap . Évalué à -5.
tiens moi je croyais que c'était une version gratuite de windows
# La question que tout le monde se pose (surtout sam) :
Posté par kadreg . Évalué à -6.
Ah, on me souffle dans l'oreille qu'il s'agit de sécurité pour la machine, et pas pour les maisons de disques qui crient très fort.
[^] # Re: La question que tout le monde se pose (surtout sam) :
Posté par Annah C. Hue (site web personnel) . Évalué à -10.
Tellement fort qu'elles te moinssent sans hésitation.
# Re: Trusted Debian 1.0
Posté par vga1523 . Évalué à 8.
[^] # Re: Trusted Debian 1.0
Posté par Misc (site web personnel) . Évalué à 2.
La réponse est simple :
si c'est pas Debian, c'est mal(tm).
Le noyau patché, c'est mal(tm), sauf si c'est fait par debian.
Plus sérieusement.
Le kernel de mandrake inclut le patch grsecurity, et la sécurisation se fait via msec, qui, par exemple, restorent les permissions, vérifient les logs etc.
La, par contre, il y a peu prés les mêmes patches, et des bianires compilés avec une version de gcc. Par contre, la partie sécurisation doit se faire comme sur une distrib normal.
Pour finir, je trouve que ces méthodes ne sont pas de vrai solution en profondeur, contrairement au audit de sécurité que OpenBSD subit réguliérement.
[^] # Re: Trusted Debian 1.0
Posté par Lionel Draghi (site web personnel) . Évalué à 3.
| msec, qui, par exemple, restorent les permissions, vérifient les logs etc.
Le patch grsecurity est d'ailleurs un vrai régal à appliquer et régler sur Debian.
Le site de grsecurity a des présentations très intéressantes sr le deal perfo/sécurité.
Quand aux autres outils, ils sont présent en abondance dans la Debian normal.
Pour s'en persuader, et puisque personne n'en à parlé, je donne l'URL indispensable pour accompagner cet article : http://www.debian.org/doc/manuals/securing-debian-howto/.(...)
Ne me remerciez pas, tout le plaisir a été pour moi :-)
[^] # Re: Trusted Debian 1.0
Posté par Erwan . Évalué à 1.
[^] # Re: Trusted Debian 1.0
Posté par Anonyme . Évalué à 3.
A priori, il y'a là des patchs de sécurité en plus - pas des correctifs de trous absent ailleurs, sinon c'est que « ailleurs » est défectueux.
# Et concernant les Maj de securité ?
Posté par Misc (site web personnel) . Évalué à 6.
J'ai pas vu ça dans la FAQ. J'espére que la réactivité sera bonne, meilleur que celle comme pour la mise à jour de openssl .
http://www.debian.org/security/2003/dsa-288(...) => 17/04
http://www.linuxsecurity.com/advisories/redhat_advisory-3099.html(...) => 01/04
http://www.linuxsecurity.com/advisories/suse_advisory-3112.html(...) => 04/04
http://www.linuxsecurity.com/advisories/gentoo_advisory-3042.html(...) => 24/03
[^] # Re: Et concernant les Maj de securité ?
Posté par Anonyme . Évalué à 2.
Ca paraitrait étonnant, puisque ces paquets ne sont pas inclus dans l'arbre debian.
[^] # Re: Et concernant les Maj de securité ?
Posté par Xavier Poinsard . Évalué à 0.
[^] # Re: Et concernant les Maj de securité ?
Posté par Anonyme . Évalué à 3.
[^] # Re: Et concernant les Maj de securité ?
Posté par deresh . Évalué à 2.
Je ne vois pas où est la merde, pour moi ça veut dire:
si ils sont moins reactifs, on rentre plus facilement.
Mais si, une fois rentré, on ne peut presque rien faire ce n'est pas tres grave.
(le on est un pronom indéfini, il n'est pas egale à je)
[^] # Re: Et concernant les Maj de securité ?
Posté par Xavier Poinsard . Évalué à 3.
- les vulnérabilités découvertes ne seront pas exploitables
- ou bien elles le seront plus difficilement, en tout cas pas aussi facilement que sur un système "classique"
=> Il n'est pas nécessaire de mettre à jour une application "trouée" immédiatement puisque le trou n'est pas exploitable (ou beaucoup plus difficilement).
[^] # Re: Et concernant les Maj de securité ?
Posté par Moby-Dik . Évalué à 1.
[^] # Re: Et concernant les Maj de securité ?
Posté par Xavier Poinsard . Évalué à 1.
J'ajouterais que les maj de sécurité des paquets ne corrigent que les failles connues.
Comme l'a posté Michael Scherer un peu plus bas, mettre à jour les paquets ayant des failles connues ne suffit pas à sécurisé ton système. Ce n'est qu'un élément parmi d'autres.
[^] # Re: Et concernant les Maj de securité ?
Posté par ludotux . Évalué à 7.
Même Microsoft n'est pas arrivé à rendre leurs utilisateurs aussi bêt^H^H^H attendrissants.
[^] # Re: Et concernant les Maj de securité ?
Posté par Moby-Dik . Évalué à -2.
[^] # Re: Et concernant les Maj de securité ?
Posté par Misc (site web personnel) . Évalué à 5.
Que, sous le prétexte que tu as un antivirus, tu peut te permettre de lancer tout les executables du monde ?
La sécurité est un processus, pas un produit.
# Re: Trusted Debian 1.0
Posté par Philippe Bouamriou (site web personnel) . Évalué à 4.
Vive la diversité :)
[^] # Re: Trusted Debian 1.0
Posté par j . Évalué à 5.
Ca te fait un choix supplémentaire, huhu :)
[^] # Re: Trusted Debian 1.0
Posté par Philippe Bouamriou (site web personnel) . Évalué à 1.
merci :)
# Re: Trusted Debian 1.0
Posté par zébulon . Évalué à 1.
http://www.trustedbsd.org(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.