Infos Locales : Important appel d'offres du ministère de l'intérieur
Posté par Pierre Jarillon (page perso, ). Modéré le 20 juin 2006.
Parmi les appels d'offres publiés récemment au journal officiel, il en est un qui a failli passer inaperçu. Il s'agit de « Annonce n°268 publiée le 11/05/2006 dans le BOAMP n° 090 A, Dépt. 75 » intitulée « Modernisation de messageries du ministère de l'intérieur et de l'aménagement du territoire à Paris ».
Cet appel d'offre public est important car il a pour but de faire sauter deux verrous qui freinent l'adoption des logiciels libres.
Le premier verrou est le remplacement de la messagerie Exchange 5.5 et X400 par une messagerie open source. Le but est d'offrir au moins les mêmes fonctionnalités car elles se sont souvent intégrées à la culture d'entreprise.
Le deuxième verrou est de permettre l'usage des PDA et autres Pocket PC Windows dans un environnement hétérogène. Il faut savoir que ces petits appareils sont offerts indirectement par Microsoft aux dirigeants des grandes structures. Ces cadeaux sont empoisonnés car ces dirigeants exigent ensuite de pouvoir s'en servir, souvent au grand dam de leurs techniciens. En effet, il ne fonctionnent initialement qu'avec Outlook... qui ne fonctionne qu'avec Exchange... qui ne fonctionne qu'avec Windows... C'est ainsi que le petit cadeau entraîne le verrouillage des entreprises et des administrations.
Le projet, lancé dans la discrétion, n'en est pas moins énorme tant par sa taille (environ 100 000 postes seront concernés) que par son apport aux logiciels libres. Il y a fort à parier que Microsoft va utiliser comme d'habitude tous ses moyens de pression pour essayer de faire avorter le projet.
Cet appel d'offre public est important car il a pour but de faire sauter deux verrous qui freinent l'adoption des logiciels libres.
Le premier verrou est le remplacement de la messagerie Exchange 5.5 et X400 par une messagerie open source. Le but est d'offrir au moins les mêmes fonctionnalités car elles se sont souvent intégrées à la culture d'entreprise.
Le deuxième verrou est de permettre l'usage des PDA et autres Pocket PC Windows dans un environnement hétérogène. Il faut savoir que ces petits appareils sont offerts indirectement par Microsoft aux dirigeants des grandes structures. Ces cadeaux sont empoisonnés car ces dirigeants exigent ensuite de pouvoir s'en servir, souvent au grand dam de leurs techniciens. En effet, il ne fonctionnent initialement qu'avec Outlook... qui ne fonctionne qu'avec Exchange... qui ne fonctionne qu'avec Windows... C'est ainsi que le petit cadeau entraîne le verrouillage des entreprises et des administrations.
Le projet, lancé dans la discrétion, n'en est pas moins énorme tant par sa taille (environ 100 000 postes seront concernés) que par son apport aux logiciels libres. Il y a fort à parier que Microsoft va utiliser comme d'habitude tous ses moyens de pression pour essayer de faire avorter le projet.
L'annonce (1278 hits)
Le Journal Officiel - Appel d'offres (939 hits)
Consulter les annonces de marchés publics (715 hits)
> Lire la dépêche (71 commentaires, moyenne: 3,2).
Vous avez demandé le commentaire #725135.




L'ADAE préconise déjà d'utiliser des LLs mais...
Ces appels d'offres sont logiques car ils découlent d'une volonté relativement ferme d'utiliser davantage de Logiciels Libres au sein de nos chères administrations. Pour autant, certains sociétés privées, cul et chemise avec certains de nos dirigeants, poursuivent un but très éloigné de l'intérêt commun.
En effet, il m'a été donné de voir qu'il existe dans un de nos ministères des politiques de sécurité qui demandent aux serveurs de messagerie de bloquer les fichiers au format OpenDocument sous prétexte que l'XML n'est pas sûr et qu'un organisme de sécurité de l'État a déjà réussi à écrire une macro malveillante.
En fait, la raison est que les éditeurs d'antivirus savent très bien scanner les divers documents produits par MS Office mais ce n'est pas encore le cas des documents produits par OpenOffice alors même que leurs moteurs sont portés aussi bien sous Windows que sous Linux et même parfois sous Solaris.
Microsoft n'est pas le seul à faire pression, loin s'en faut mais je connais de valeureux gendarmes qui risquent soit de tirer la gueule, soit de faire pression à leur tour.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
... les gendarmes qui bossent sur internet preferent linux pour remonter les sites dynamiques sans s'emmerder outre-mesure. :)
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
C'est possible sous OO? Parce qu'avec PerlTeX le mode sandebox est activé par défaut ...[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
C'est possible sous OO?
On s'en fout il suffit juste de dire que ça existe. Ça fera vendre la prochaine version de l'anti virus qui les enlève.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
OpenOffice.org te demande confirmation avant d'executer une macro, mais après, la macro peut à peu près tout faire sur ta machine (cf. dicooo qui télécharge et installe des dictionnaires comme un grand).
Comme word, en fait de ce que j'en sais.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Dans la limite des droits correspondant a ton utilisateur. Et mine de rien, une telle "limitation", ce n'est pas rien !
PlexiWeb, l'hébergement simple et rapide - http://www.plexiweb.net/
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Qu'y a t-il de plus grave ?
Personnellement, je m'en fout (royalement) du "système". Il me suffit de mettre le CD de ma distrib préféré dans le lecteur et en 30 minutes le problème est réglé.
Par contre, le fait que mes données utilisateurs (mon /home) soit exposées est bien plus grave. Il serait temps de revoir les positions sur la sécurité.
(je parle bien d'un poste de bureau, qui irait utiliser OOo sur un serveur ?)
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Ce que tu dis est évident mais l'ancienne vision continue à être pertinente.
Si on interdit qu'un fichier utilisateur soit executé (/home, /tmp... en noexec),
une macro malveillante a beaucoup moins de possibilités de nuisance car
elle ne peut agir que quand on l'exécute. Si tous les virus, malware et autres
spyware avaient les mêmes restrictions, on est plus obligé de refaire des
installations parce qu'il y a des bouts de trucs dans tous les fichiers systèmes,
une machine fraîchement installée ne se retrouverai pas complètement
vérolée avant même qu'on ait pu installer les mises à jour de sécurité....
Il est évident qu'on peut et qu'on devrait mieux faire mais c'est déjà beaucoup.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Il est possible d'avoir deux comptes utilisateurs. Un pour ce qui concerne internet(E-mail, lecture de documents en tout genre venu de partout), l'autre pour tout ce qui est privée et de confiance(documents boulots, photo de famille, ...). Il est possible de se protéger en se basant sur les droits, qui ne sont pas forcément là que pour protéger le système.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Une autre solution developpé dans une conférence [1] explique qu'il faudrait lancer toutes (absolument toutes) les applications dans une cage (chroot). De cette façon, la protection est maximum. Reste quelques points à résoudre (notamment les accès aux fichiers de l'utilisateur dans la cage)
En plus de ça, un système de fichier versionné (CVS, SVN ou autre) rassure énormement.
[1] La vidéo est très intérressant, je la recommande :
http://rehash.xs4all.nl/wth/rawtapes/wth_client_security_is_(...)
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
C'est quoi le rapport avec OpenOffice.org Vs Word ?
Là, tu parles de Windows mal utilisé vs Unix bien utilisé, non ?
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
> Comme word, en fait de ce que j'en sais.
pas tout à fait. Word exécute les macros dans une sandbox.
La différence est fondamentale.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Pas depuis longtemps si mes souvenir sont bon...
Et il me semble avoir vu un "security advisory" comme quoi il étais possible d'en sortir via un bug...
Donc bon...
Il m'est d'avis que lancer un document non sur via : sudo -u testuserXYZ ooowriter fichier.odt
et bien plus sur, c'est ton /homt/testuserXYZ qui sert de chroot pour tester le script.
Perso c'est ce que je fais pour a peu près tout (sauf pour mes logiciel tournant avec wine don't j'ai rien a faire, z'ont accès qu'a ~/.wine et il se prennent un kill -9 a la fin de leur utilisation sur tout les process wine, comme ça pas de problème)
Comme qui la séparation des privilèges est vraiment la sécurité la plus sure...
site perso : http://rapsys.free.fr/
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Pour wine, a une époque il existait un script fournis avec le paquet debian: winechroot.
Toutes les applications web qui recontraient un fichier .exe proposaient de l'ouvrir dans winechroot.
Je ne sais pas pourquoi il n'existe plus de nos jours.
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Bonjour,
je me permets de réagir à ton message. Si l'on parle bien de la même passerelle de messagerie, et j'en connais pas 25 dans les différents ministères qui bloquent le XML et analysent les fichiers office pour en retirer le code offensif, je tiens à préciser quelques points en tant que responsable technique de cette passerelle de messagerie.
* Ce n'est pas la méchante société privée qui a pris le parti de bloquer les documents XML. Nous ne faisons qu'appliquer les consignes que nous donnent ce fameux organisme de sécurité de l'état. Oui, c'est débile de bloquer XML pour le commun des mortels mais non ça ne l'est pas dans le contexte sensible de cette passerelle, chose que tu n'as pas précisé.
* Pour ton info, les pressions pour supporter les formats opendocument ont déjà commencé en vu de l'extension du périmètre de cette politique et, tiens toi bien, le méchant industriel fait parti de ceux qui poussent à l'ouverture de ce format ! la pression est actuellement sur ce fameux organisme de sécurité pour que ce dernier :
- justifie pleinement les blocages demandés mais ça c'est pas dur, cf conf de filiol au sstic cette année
- se débrouille pour imaginer une solution de détection
- en dernier recours, après analyse du risque, accepte de laisser passer ces formats
* effectivement les produits utilisés pour nettoyer les documents bureautiques marchent uniquement avec les documents MS office pour l'instant. Désolé mais c'est dans la logique du marché pour l'instant. si le ROI pour le support de format devient intéressant, la situation changera, en attendant on bloque.
* Oui, les gendarmes ralent et ce n'est pas les seuls. mes collègues qui travaillent pour eux le font avec openoffice et ralent aussi. Mais c'est comme ça.
en espèrant avoir dissipé quelques malentendus.
bonne journée
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
C'est pas grave, j'imagine que les utilisateurs emmerdés font tout pour que cela marche : zip avec mot de passe, utilisation de bzip, utilisation de plusieurs niveau de compression, changement du nom en nom d'image, utilisation de messagerie personnel sur webmail, utilisation de transfert ftp, ...
Bref, tout ce qui est possible de faire pour continuer à bosser sans surtout être emmerdé par les pseudo mesures de sécurité... (note le second degré)
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
zip avec mot de passe <- bloqué
utilisation de bzip <- pris en charge
utilisation de plusieurs niveau de compression <- pris en charge
changement du nom en nom d'image <- on se base pas sur l'extension pour reconnaitre un format ....
utilisation de messagerie personnel sur webmail <- pas mon problème, c'est celui d'un autre indus
utilisation de transfert ftp <- pas mon problème, c'est celui d'un autre indus
faut comprendre un truc : cette messagerie (celle qui bloque les xml et provoque les ralements du monsieur au dessus) est placée en interconnexion d'un réseau *sensible* utilisé par beaucoup de non geeks donc ok, on peut raler sur le blocage de xml mais c'était une mauvaise idée de le faire sur *ce cas précis*. donc il n'y a pas de contournement à 2 francs comme on peut le faire sur un av personnel de base ni de pseudo mesure de sécurité et OpenDocument est bloqué pour une raison valable *DANS CE CAS* (j'espère avoir été assez clair).
merci de ne pas généraliser le cas général avec un cas particulier bien précis, ça évitera les réflexions à 2cts. sur les méchants industriels maqués avec MS, les vendeurs d'AV verreux, etc.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Page html avec une partie du zip en commentaire et le reste dans une autre balise ?
Fichier à l'interieur d'une image (champ EXIF et co) ?
Tu fais quoi si une des archives a un niveau quelconque de compression a un fichier de 17 Teraoctect ?
Et la question la plus importante, c'est quoi la raison valable ?
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
bon,
je n'ai pas envie d'ergoter pendant des heures donc je vais faire en sorte de mettre à fin à la discussion.
je ne cherche pas à bloquer des fichiers pour le plaisir de bloquer des fichiers,
je cherche à protéger les utilisateurs.
les 2 1ers points que tu cites nécessitent de la part du destinataire une action supplémentaire d'extraction du fichier, outils qui ne sont pas installés normalement sur les postes des utilisateurs et qui n'ont pas les droits pour le faire. Si le destinataire a installé l'outil pour extraire ces formats, il est déjà en violation de la politique SSI donc à lui d'assumer.
avant que tu ne rétorques "ouais mais si ça extrait le fichier infecté via l'exploitation d'une faille en utilisant un shellcode dans le mime type ou si un script est livré avec, tu te fais avoir, t'es vraiment trop nul, haha", je précise que tout ce qui s'apparente à du binaire (et assimilé via encodage en unicode ou autre) et tout ce ressemble de près ou de loin à un script est systématiquement bloqué.
le dernier point est un faux problème depuis un paquet d'années pour les applications d'analyse de contenus un tant soit peu sérieuse... excuse moi de dire cela assez brutalement mais le fait que tu cites cet exemple comme un problème potentiel donne, imho, une idée sur ton niveau de compètence concernant le sujet de la discussion.
avec ma dernière phrase, j'ai l'attaque personnelle, il me reste à rajouter que oui, c'est une politique de sécurité de nazi. Comme ça, j'ai aussi le godwin, ce qui va permettre de mettre fin à la discussion.
quand à la raison valable, comme tu as l'air d'être du genre super l33t en sécurité, je te laisse la deviner.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
J'avais planté un serveur mail de l'armée avec mon dernier point.
Et puis si ton application veut analyser du contenue au 25iéme niveau de compression, elle n'a pas le choix, il faut qu'elle decompresse d'une façon ou d'une autre.
A moins qu'on est configuré une limite et dans ce cas, on rejette les fichiers joints bizarre.
Tu n'es pas un peu enervé ?
Passé une mauvaise journée ?
L'application n'est pas homologué ?
Personne n'ose ecrire un script pour virer les macros des fichiers qui sont pourtant dans un format connus donc manipulable ?
Un fichier word c'est du binaire à volonté et je crois pas que microsoft a donnée de la doc sur le format.
Au contraire tu vient juste de la relancer :)
Proteger des utilisateurs en leur empechant l'accés à ce qu'ils ont besoin, c'est contre-productif et a long terme ca nuit TRES fortement à la securité.
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
alors, tout d'abord mes excuses pour le ton limite violent.
me suis vénère ce matin suite au post initial complètement HS & plein de mauvaise fois sur les méchants indus véreux maqués avec les grands pontes, la débilité d'un système dans lequel j'ai mis bcp de neurones, etc,etc donc désolé, me suis vengé bétement. Là ça va mieux après un bon acharnement sur mon rameur :o)
vais essayer d'être assez clair sans trop m'épancher non plus et après fini.
donc :
* oui, les fichiers de type container (zip, office, etc) nécessitant une analyse dites récursives ont un seuil autorisé de récursion. Ce seuil a besoin d'être assez élevé en partie justement à cause des documents office (.doc -> ole -> excel -> ole -> ....) d'où la nécessité d'introduire également une limite sur le temps d'analyse et sur l'espace mémoire occupé par la version décompressé (afin d'éviter le zip de 1ko décompressé en 4 Go). si tu es tombé sur un serveur de l'armée qui s'est vautré avec ce genre de pb, shame on them...
* les odt, xml, etc sont pour l'instant bêtement bloqués car il existe une possibilité (non théorique) de détourner ce format dans un but offensif via, je crois, l'utilisation de xslt, etc. Ce que l'on ne peut se permettre dans un contexte sensible qui est celui de la plate forme de messagerie si méchante envers les gentils geeks. Le but de la passerelle n'est pas que transférer des mails et faire râler les linuxiens mais il est également d'assurer le niveau maximal de sécurité sans passer par un sas de transfert manuel (un antivirus humain en quelque sorte ... ;o) )
* le problème des macros n'en est plus trop un dans le cas de office via certains éditeurs d'av mais l'est, et de façon encore plus dangeureuse que ms office (pas de sandox) dans le cas de openoffice. Même cause, même conséquence -> on peut pas se le permettre.
* le problème est que développer un plugin de suppression de macros pour ce format coute très cher et nécessite des grosses compétences dans des domaines particuliers. dans la mesure du possible on évite les scripts perl one shot qui marchent que sur 3 fichiers de test et basta. Derrière y'a 20k users qui risquent de pas être content et de taner la chaîne de support.
J'ose même pas imaginer le coût d'un plugin d'analyse du format xml...
* De plus, l'organisme protégé par cette fameuse passerelle a homologué un format bureautique et ce format, c'est office 97 ! ben ouais, c'est con à dire mais l'état c'est pas crésus et l'argent investi dans les licenses et la formation ne peut être ignoré. Bien sur, au gré des projets, cd piratés refilés par le beau frère, etc y'a du 2k et du 2k3 qui se promènent et on fait pas les batards non plus quand un problème remonte concernant un fichier office 2003. Mais bon, c'est pas mère thérésa land non plus. Donc si le client veut le support xml & macro openoffice de façon + intelligente que le blocage actuel, ben il paye ou le fait lui même.
* concernant le débat que j'ai relancé bien malgré moi, cf ci dessus. Les utilisateurs sont sensés avoir office et leurs correspondants aussi. Ce format est reconnu comme format d'échange donc on a fait le max pour permettre ça sans diminuer le niveau de sécurité. Lorsque le format opendocument sera soit très répandu soit déclaré comme norme de communication standard, le boulot sera fait.
Il faut comprendre que les formats bloqués sont les formats "dangeureux" et uniquement lorsque l'on ne peut pas les nettoyer avec confiance.
dans 99% des cas, les documents office + pdf + image, etc ça suffit à ces utilisateurs. C'est une messagerie pro après tout. Alors bien sur la dernière blague au format exec qui affiche une nana avec les seins qui bougent sur le bureau ou le super activex à la mode qui fait des wizz dans IE passent pas mais bon, perso ça me pose pas de cas de conscience :p
en espérant avoir éclairci les interrogations et répondu aux questions.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
D'abords, merci pour ces infos, c'est très sympa de votre part!
Si je comprends bien le schmilblik:
*l'État dispose des compétences, mais pas forcément de l'argent nécessaire pour dégager le temps nécessaire à ce développement (en engageant des assistant pour les taches demandant des compétences plus communes par exemple).
*l'éditeur ou l'État n'ont pas envie d'engager un prestataire extérieur (très/trop cher) pour faire ce développement.
Alors, est ce qu'il est possible, si l'éditeur est en croissance, de leur suggérer d'intégrer ce développement via leur processus de recrutement? Par exemple des stagiaires (futur employé de l'éditeur) du Magistère sécurité de l'ENST. Surtout qu'il me semble qu'un certain nombre de personnels de l'armée (ou futur pour les Polytechniciens) font cette formation (en formation continue, donc déjà compétent).
Pis ça devrait caresser l'éditeur dans le sens du poil de faire travailler des gens pour pas cher :p
La déclaration en norme de communication reconnue par l'État, c'est en très bonne voie, non? Il me semble que l'odt&co sont déjà des normes ISO, et qu'il y a des projets de lois à ce sujet en France et dans d'autres pays euopéens.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
les odt, xml, etc sont pour l'instant bêtement bloqués car il existe une possibilité (non théorique) de détourner ce format dans un but offensif via, je crois, l'utilisation de xslt, etc.
Pour ce qui est du XML en générale, je ne suis pas sûr de bien comprendre le problème des xslt (que tu crois, d'ailleurs...) Quelqu'un peut-il confirmer ? Et n'existe-t-il aucune expertise et filtre efficace (pour sécuriser) ?
Lorsque tu parles d'un plug-in pour supprimer les macros, je crois d'abord comprendre qu'il s'agit des documents OpenDocument je fini par comprendre que tu parles des fichiers XML en générale. Hors, XML est un métat-format permettant de définir des formats de fichier structurés, avec des outils génériques permettant de manipuler ces structures. Je n'ai pas encore entendu parlé des "macro XML"... Je pense donc qu'il doit s'agir des macro contenues dans les documents OpenDocument, c'est à dire, des fichiers XML faisant référence à un descripteur bien particulier qui à un niveau supérieur présente certaines informations comme étant des macros destinées à être interprétées comme telles par les programmes qui supportent l'exécution de ces macro...
Enfin, bref, j'en retien le sentiment d'une certaine confusion entre XML et OpenDocument (basé sur XML). C'est un peut comme bloquer les fichier texte... Et quid des pages web XHTML ? bloquées aussi ?
Pour ce qui serait d'un plug-in supprimant toutes sortes de macros contenues dans tous fichier de type XML, je pense que cela est infaisable tant il existe des formats de fichier basé sur XML, présents et à venir, publiques et "privés" (DTD non disponible).
Pour ce qui serait d'un plug-in supprimant les macros des fichiers OpenDocument (basé donc sur XML mais référent à quelques DTD publiques), je pense que cela doit être facilement faisable et peut-être même que la communauté à déjà fait cela. En effet, il ne faut pas oublier les avantage d'un format ouvert..., une communauté y travail et partage... Un tel plug-in en intéressera d'ailleurs probablement plus d'un...
Je comprend et j'approuve l'application (dans certains cas) de la politique qui concise à identifier le type d'un fichier et selon possibilité, le rejette, le sécurise ou le laisse passer tel quel. Un fichier ne pouvant pas être sécurisé sera rejeté.
Il est regrettable que certains fichiers ne puissent être sécurisés du fait qu'il utilisent un format aillant pourtant ces avantages et relativement utilisés.
Le format OpenDocument n'est-il réelement pas sécurisable ? ou est-ce un manque de réactivité de quelques éditeurs / développeurs trop "autoritaires"(/puissants) du fait d'un modèle de développement fermé ?
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
ce qui est sûr, c'est que si il faut bloquer le xml à tous les niveaux (http et mail), on se retrouve sous windows dans une situation étrange où certains outils de sécurité comme mbsa/sms/wus ou hfnetchk ne peuvent plus récupérer leurs mises à jour, ce qui empèche de mettre à jour correctement les postes de travail et serveurs windows...
Donc en bloquant le xml (en http), on peut réduit la sécurité des systèmes windows.
Je suis certain qu'une règle de sécurité interdisant l'entrée dans l'entreprise de documents xml est plus dommageable que bénéfique.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
quand à la raison valable, comme tu as l'air d'être du genre super l33t en sécurité, je te laisse la deviner.
dommage personnellement c'est la *seule* réponse qui m'aurait intéressée.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Oh, ça, on s'en fiche, la première règle de filtrage concerne la taille des pièces jointes. Faudrait pas confondre SMTP avec FTP, non plus.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Heu ...
On peut parfaitement avoir un fichier .rar de quelque ko qui aprés decompression pése 17 To.
Un petit exemple: http://www.pearpc.net/files/macosx_6gb.rar
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Tes antivirus ne savent pas detecter qu'un fichier est en faite une archive zip renommé ?
Et ils ne savent pas dezipper ?
Et même si ils ne le savent pas, tu peux toujours ecrire un script qui supprimerait a LA-RACHE tous ce qui n'est pas du texte.
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
je vois pas le rapport.
Les produits utilisés savent détecter un zip renommé et l'ouvrir, analyser le contenu, etc etc mais le problème n'est pas là. Le problème vient de l'utilisation du format XML et des macros openoffice *POUR L'INSTANT*.
Donc ne pas savoir ouvrir un zip ou bloquer du texte n'a rien à voir là dedans. En plus, je vais te faire une révélation : une page html envoyée par mail et contenant un script offensif encodé en unicode est ... du texte !!! damned !
De plus, supprimer (surement pas à l'arrache) tout ce qui n'est pas du texte, c'est antiproductif. Le but est d'avoir le meilleure compromis entre les fonctionnalités et la sécurité, pas de forcer les gens à utiliser mutt & vi pour leurs correspondances.
[^]Hors sujet
Bah quoi ? C'est ce que j'utilise. :-)
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Le problème n'est pas le xml, mais la médiocrité des systèmes supposés le prendre en charge côté client.
Une passerelle mail avec une sécurité trop restrictive est généralement une preuve de manque de maîtrise de la sécurité des clients, d'un manque de maîtrise du sujet sécurité en général, et provoque surtout des problèmes de communication et de productivité, et lorsqu'une passerelle de communication devient un problème de communication, on peut parler d'échec.
Dans tous les cas, il est indispensable de permettre aux utilisateurs de récupérer des pièces jointes bloquées (pour lesquelles aucun virus n'a été détecté) de manière plus ou moins automatique (questionnaire en ligne posant des questions sur l'expéditeur et évaluant le risque avec responsabilité de l'employé engagée en cas de problèmes si celui-ci a répondu incorrectement) sous peine de nuisances sérieuses à la productivité.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Au final quand le système est idiot, on le contourne, je bosse pour la Défense où les mails avec des pièces open office sont considérés comme virus et donc rejetés, du coup on utilise notre boite email perso et on transfère par clé usb au mépris de toutes les règles SSI, mais bon il faut bien bosser.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Totalement faux, un document openoffice, de par sa nature xml, n'est qu'un fichier texte. Je ne vois pas en quoi un antivirus aurait du mal à scanner un fichier texte pour y retrouver une macro malveillante. Si un virus frappant openoffice faisait parler de lui, les antivirus seraient rapidement mis à jour pour le détecter.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Un fichier OpenDocument est une archive ZIP qui contient plusieurs document XML et éventuellement des marcos java compilées. L'un dans l'autre les éditeurs d'antivirus savent déziper, lire du XML et vérifier des .jar...
PS: il y a aussi des macros pyhton basicooo et beanshell mais elle ne sont pas à l'état compilé.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
"En effet, il m'a été donné de voir qu'il existe dans un de nos ministères des politiques de sécurité qui demandent aux serveurs de messagerie de bloquer les fichiers au format OpenDocument sous prétexte que l'XML n'est pas sûr et qu'un organisme de sécurité de l'État a déjà réussi à écrire une macro malveillante."
Les forces vives de ce Ministère et son RSSI doivent être largement plus compétents que l'O.T.A.N. Openoffice est agréé par l'O.T.A.N. et a été utilisé comme plateforme de messagerie commune entre les diverses forces publiques lors du sommet du G7 à EVIAN ! Qui est le RSSI super pointu de ce Ministère qui connait bien les failles de ODT et la supériorité des .DOC en matière de sécurité ?
C'est rassurant d'avoir de telles pointures dans notre administration !!
[+] [^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
tiens, je viens d'apprendre que Openoffice est une plateforme de messagerie. On en apprend tous les jours sur DLFP ^_^
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Oui , comme "plate-forme Bureautique" , MEA CULPA . Tous le monde aura rectifié, sauf un . Mais pour certain , la forme est plus importante que le fond .
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
L'ADAE préconise déjà d'utiliser des LLs
L'ADAE préconise d'utiliser des formats interopérables (donc généralement des standards ouverts, sauf lorsque celà est en contradiction avec la priorité d'intéropérabilité / large support - ainsi mp3 est préconisé, à juste titre, au détriment de ogg qui est moins universel).
Mais l'ADAE ne préconise en aucun cas d'utiliser des LLs. Elle ne préscrit pas d'implémentation spécifique. C'est bien ce qui lui donne sa légitimité: rester neutre , vendor agnostic, pragmatiques, et centrés uniquement sur l'intéropérabilité. Irréprochable, même par nos ennemis, en somme.
C'est sur ce point que se fourvoient beaucoup de contributeurs du wiki ADAE avec des remarques comme « choisissont le format X, car bien que mal supporté dans la plupart des cas il est poussé (ou : le seul supporté) par le logiciel libre Y »: promouvoir le logiciel libre Y n'est pas la mission d'ADAE.
Cette réthorique décridibilise un peu l'ensemble du travail (qui ne mérite pas ça). Ayez plus confiance dans les LL: si l'intéropérabilité (et rien qu'elle) est privilégiée, ils sauront s'imposer ! De même: les décisions orientées seulement par l'intéret commun public suffiront à promouvoir l'utilisation du logiciel libre, inutile ici de se laisser aller au lobbying bas étage comme nos concurents, qui ne se préoccupent pas du bien commun (« tachons d'imposer la norme / le format que nous supportons le mieux pour tuer nos concurents »), pour une fois qu'un organisme d'état décide de choisir une solution pour d'autres raisons que « les logiciels auquels ont est habitués » ou «les sociétés avec lesquelles on a des partenariats ».
Si l'ADAE déroge à cette neutralité pragmatique, ils offriraient alors aux éditeurs de solutions propriétaire une occasion révée d'invalider leurs décisions comme anti-concurentielles, unfair, etc.
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
L'appel d'offre n'est-il pas tout simplement obligatoire ?
[^]Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Comprendre "ce type d'appel d'offres, faisant appel la part belle aux logiciels libres"...