> Je suis desole vous m'enleverez pas de la tete que si vous voulez que
> monsieur ou madame tout le monde utilise The gimp pour retoucher ses
> photos il faut que le plugin red-eye soit ameliore.
Mais qui t'a dit qu'on voulait que monsieur et madame tout le monde utilise
The gimp? En ce qui me concerne, j'ai installé ce programme pour essayer et
je l'ai tout de suite viré: trop compliqué. J'ai des besoins simples. Je veux
pouvoir faire tourner une photo de 90 degrés pour qu'elle soit dans le bon
sens. Je veux pouvoir faire un peu joujou avec la balance des couleurs et
avec le contraste pour compenser le fait que je ne sais pas me servir d'un
appareil photo. Je veux virer des yeux rouges. Pas plus.
Pour mes besoins, The gimp est une usine à gaz incompréhensible et
j'imagine que c'est aussi le cas de monsieur et madame tout le monde.
Biensûr, si monsieur et madame tout le monde s'intéresse vraiment à la
retouche photo, grand bien leur fasse. Il comprendront alors aisément que
ce genre d'activité ne s'improvise pas et qu'il faut du temps pour maitriser
un outil comme The gimp (ou photoshop). Et une fois cette phase
d'apprentissage finie, ils sauront virer des yeux rouges en trois cliques sans
pluggin spécifique.
Je viens de l'installer et je me pose des questions.
J'ai déjà quelques bouquins sur ma machine grace au projet
Gutenberg (ce sont des fous). Je viens de vérifier, il y a des
textes dans cette encyclopédie que je n'ai pas trouvé sur
Gutenberg. L'inverse est bien évidemment vrai.
Voici donc mes questions:
1. Sous quelles licences sont distribués ces textes?
2. Quel est le format précis de la base de donnée? Ça, c'est pour convertir
les oeuvres Gutenberg que j'aime pour pouvoir tout centraliser.
3. Serait-il possible de fournir au projet Gutenberg les textes qu'ils n'ont pas?
Pour ce qui est du 2., si le format n'est pas trop tordu, il doit même
être possible de faire un script de conversion enclitt <-> Gutenberg
Pour ce qui est de l'argument "un ordi sans OS, ça ne sert à rien".
J'avais lu sur linuxfr une comparaison très parlante.
Imagine que tu achètes un magnétoscope et on te vend avec "Independance day".
Toi, tu n'aimes pas "independance day". Tu vas voir le marchant et tu lui expliques
que tu veux le magnétoscope sans la cassette vidéo. Et lui de te répondre qu'un
magnétoscope sans cassette vidéo, ça ne sert à rien.
Je distingue deux parties dans le travail de journalisme:
- Informer;
- Commenter l'information.
La seconde partie me semble au moins aussi importante que la première.
Or pour commenter, il faut faire des choix. Par exemple, le projet de
constitution européenne. Le texte fait quelques centaines de pages si on
compte les annexes. Je ne pense pas qu'on puisse objectivement résumer
cette constitution en une centaines de lignes sans être partisant. Il est
normal qu'un journaliste soit partisant mais la nature de kiwipedia/kiwibidule
me semble incompatible avec cela.
Je pense donc qu'un système de journalisme communautaire ne peut pas
surpasser un bon journaliste. Ceci-dit, tous les journalistes ne sont pas de
bons journalistes et trop souvent, les articles que je lis ressemble aux nouvelles
de l'AFP en un peu délayé.
> on ne donne/prend pas d'antibiotiques pour un rhumes messieurs !
Je me permets de préciser pourquoi ça ne sert à rien, on ne sait jamais.
Un antibiotique s'attaque à des microbes. Ceux-ci sont des être vivants
qui peuvent se reproduire seuls.
Un virus n'est pas un être vivant. Il se reproduit en parasitant des cellules
qui se mettent à pondre du virus. Un antibiotique n'a donc aucun effet sur
un virus et comme un rhume, c'est causé par un virus...
Je suis globalement d'accord avec toi mais en fait non.
Je m'explique. Il y a des choses que l'on peut déployer partout facilement (W^X
et autres joyeusetés). Ensuite, une politique de sécurité passe par définir ce que
les personnes/processus doivent pouvoir faire (tout le reste étant interdit).
Je trouve que les distributions (dans leur grande majorité) ne semblent pas
s'impliquer activement dans ce genre de politique volontariste. W^X, execshield
et autres ne sont pas la norme. De plus, en ce qui concerne la sécurité, il y a
des gens qui développent des outils (SELinux, grsec...). À d'autres de les utiliser.
Il ne me semblerait pas abérant que /home soit monté par défaut en /noexec.
Pour une machine de bureau, soit l'utiliseur est root, soit il n'a pas à installer
de programmes. Dans le cas contraire, la machine est administrée et libre à
celui-ci de changer le ligne correspondante dans le fstab. Or, ce n'est pas le cas.
Apt-get (et j'imagine urpmi) n'authentifient pas par défaut les serveurs et les
paquets qu'ils installent. À la limite debian a un fonctionnement
ultra-conservateur ce qui peut expliquer cela mais redhat peut imposer ce
genre de choses. Et si c'est effectivement intégré aux outils, les gens l'auront
rien à faire de plus.
Une vraie politique forte de sécurité est forcément intrusive mais je pense qu'il
reste des choses à faire qui ne sont pas trop contraignantes pour améliorer
globale d'une distribution.
je continue à trouver ton premier commentaire un poil agressif mais ton second
me plait pas mal. Comme tu l'as noté, il y a un certain nombre de choses qui se
font pour sécuriser une machine Linux (SELinux, grsec, pax...)
Et la mise à jour d'un système reste une partie délicate.
Au final, ce que je propose n'est rien d'autre qu'une façon violente de gérer ce
problème de mise à jour.
Un utilisateur technophile a plus de chances d'avoir un comportement sain
vis-à-vis de la sécurité informatique (ne pas rester toujours en root, ne pas
ouvrir tous les mails bizarre...). Cependant, un certain nombre de distributions
visent directement un utilisateur moins « chevronné ». Celui-ci doit être éduqué
mais il me semble plus important d'avoir une politique plus volontaire concernant
la sécurité pour ces personnes. Il me semble que les outils de sécurité mentionné
peuvent être déployé sans trop géner l'utilisateur. Or, à ma connaissance, ils
restent confiné à des niches de spécialites.
Je trouve cela dommage car si pour le moment, Linux n'est pas une cible
importante pour les virus et autres spyware, il est en train de le devenir et si
les éditeurs ne font rien, les machines Linux vulnérables qui se baladent dans
la nature vont finir par devenir un problème.
Heuuu...
Non.
La seule raison pour laquelle j'ai mentionné OSX est que c'est le premier
unix orienté desktop dont j'ai entendu parlé qui s'arrange pour « virer »
root. Et je trouve que c'est bien.
> Bha il ecrira son code en Perl :-)
:) Ça rejoint ce que je disais pour les virus de macro.
Si son fichier à les droits en exécution, c'est un exécutable et il est traité
comme tel. Sinon, il faut faire
# perl virus
et là, pour augmenter la sécurité, il faut changer l'utilisateur. Je suis bien
convaincu que le fishing et autres techniques de social engenering sont
applicable mais c'est autre chose.
Oui, ce que je veux, c'est du SELinux ou autre et oui encore, le
problème se pose quand on fait une mise à jour.
Si on arrive a mettre en place un système de clef, de sertificat ou autre, on peut
être à peut près sûr de faire une mise à jour depuis le bon site. Évidemment, si
le site est compromis, on est eu.
Au moment où on fait l'installation, la machine est plus vulnérable car on doit
authoriser certaines opérations dangereuses (écrire sur le disque). L'idée est
donc de passer temporairement dans un environnement beaucoup plus contraint
(sans réseau, sans serveur d'impréssion, éventuellement sans serveur
graphique). Une telle configuration n'est certe pas viable en utilisation courante
mais juste pour une installation de programmes, cela me paraît convenir.
Et je vois mal comment une attaque réseau peut être réalisée si
- le système est sain;
- les fichiers à installer sont authentifiés;
- aucune communication avec l'extérieur n'est possible.
Biensur il reste possible de modifier les fichiers de configuration qui se trouvent
dans /etc. Mais il y a rarement une option « installer une backdoor »
configurable dans /etc dans les programmes normaux.
Je sais bien que la sécurité absolue, ça n'existe pas, je sais bien qu'il y aura
toujours des trous de sécurité. Je sais bien qu'on ne peut pas être sûr que les
mesures de sécurité mises en place ne seront pas détournée.
Ce que je cherche, ce n'est pas la sécurité absolue: la sécurité informatique
absolue, c'est de ne pas avoir d'ordinateur. Ce que je cherche, c'est comment
microsoft, apple ou redhat peut s'arranger pour rendre son système plus sûr
de façon notable sans faire chier le client. Car la sécurité, c'est avant tout
quelque chose de chiant et de pénible car c'est avant tout quelque chose qui
contrôle et qui interdit.
Je pars du constat qu'une machine windows non administrée se retrouve vite
bourrée de spywares, virii et autres. Si on excepte les virus de macro et les
chevaux de troye, ce genre de chose existe parce que du code à pu s'exécuter
sans que cela ait été voulu. Pour se protéger de ce genre de chose, il faut donc
éviter qu'un bug puisse conduire à l'execution arbitraire de code. Une première
approche consiste à empêcher cette exécution très tôt (W^X, malloc
randomisé, etc...). Maix comme tu le dis si bien, il se peut qu'un attaquant
arrive quand-même à faire exécuter son programme. Or l'une des premières
choses que l'attaquant va essayer de faire, c'est rendre cet exécution pérène.
Si un simple reboot permet de virer tous les spywares et tous les virus,
l'attaquant n'a pas gagné grand chose. Pour péréniser son attaque, il doit
pouvoir écrire sur le disque des informations. De plus, ces informations doivent
être exécutée de façon automatique. Ce que je propose a pour but de rendre
cette seconde étape plus difficile.
Si toutes les partitions sur lequel un utilisateur peut écrire sont montées en
noexec, c'est déjà un premier pas. Cependant, comme l'attaquant est fourbe,
il va trouver une faille de sécurité et arriver à devenir root. Dans ce cas, il
peut écrire dans /etc/rc2.d pour que son truc se lance au démarrage. Si
on s'arrange pour que root ne puisse pas écrire dans /bin /sbin /usr /lib...
et qu'un programme doive faire partir d'un de ces répertoires pour être lancé,
la tâche de l'attaquant devient plus dur: il doit trouver le moyen pour rendre
à root les droits d'écriture aux endroits ou il ne les a plus.
Evidemment, ce n'est pas complètement sûr mais ça complique la tâche de
l'attaquant.
Le terme rook-kit était mal choisi.
À priori, ce genre de technique empèche un spyware de s'installer sans l'accord
explicite de l'utilisateur. Il faut que le spyware ailles se copier dans la zone
d'installation, attendes le reboot et à ce moment, il faut que l'utilisateur accepte
d'installer un programme qu'il n'a pas demandé.
De plus, si le système n'accepte d'exécuter que des binaires venant de la
partition « binaires », cela empêche aussi le spyware de se placer dans le
/home et de modifier le .xsession (ou autre technique de ce genre).
Cela n'empêche pas les chevaux de troie ni les virus de macro et cela ne garantit
pas l'intégrité des données de /home mais c'est une protection beaucoup plus
importante.
Je ne dis pas que ma technique est l'arme ultime mais que c'est une façon pas
trop intrusive d'augmenter de façon importante la sécurité. De ce point de vue,
demander à l'utilisateur de faire des mises à jours toutes les semaines est plus
contraignant, même s'il vaut mieux le faire. De plus, certaines personnes n'ont
pas encore l'ADSL et sur un modem RTC, les mises à jours...
Rien n'empêche d'imposer la présence d'au moins un caractère alphanumérique,
d'un symbole de ponctuation et de majuscule.
Me9do!r
ne me semble pas un si mauvais mot de passe. Après, comme j'imagine que
personne ne change son mot de passe, ça ne doit même pas leur coüter trop cher
de faire une petite vérification par dictionnaire.
J'ai beau regarder. Qu'une machine qui est de toute manière éteinte tout
les soirs soit rebooté de temps en temps pour faire une mise à jour système
ne me choque pas.
root, ce n'est personne d'autre que l'utilisateur d'UID 0.
Rien ne t'empêche de renommer root en zorglub. Globalement, ça marchera pareil
sauf que certains programmes ont "root" codé en dur.
Ensuite, la méthode OSX est de déactiver le passwd root et de mettre un
utilisateur "admin" en sudoer. Par exemle le fichier sudoers suivant donne tous
les droits à zorglub. La dernière ligne est faire pour qu'il faille TOUJOURS donner
le passwd.
User_Alias ADMIN = zorglub
ADMIN ALL= PASSWD: ALL
Defaults timestamp_timeout=0
Ensuite, on utilise un utilisateur normal pour l'utilisation normale.
Il faut voir de quoi on parle. Je ne parle pas d'un serveur qui ne doit jamais
rebooter.
Pour la machine de beau papa qui installe 2 programmes par an et qui éteind
religieusement sa machine tout les soirs, ce n'est pas deux reboots de plus qui
vont l'embêter. Or, il est important de sécuriser aussi la machine de beau papa.
L'administrateur qui gère 3000 machines ne va pas s'amuser à changer la
configuration des 3000 machines tous les jours. Il va se contenter de faire les
mises à jours de sécurité (ce qui demande déjà pas mal de boulot) et il va
administrer son réseau. S'il n'est pas con, il va aussi s'arranger pour avoir le
moins de boulot possible. Il ne va donc pas installer apache sur la machine d'une
secrétaire. Idéalement, il y aura un gros serveur d'application avec des clients
légés. Dans ces deux cas, l'immense majorité des machines n'auront que peu
de programmes différents d'installés et donc le nombre de mises à jours de
sécurité sera faible (en 2004, il y a eu 9 security/advisories pour netBSD dont
une pour ftpd, une pour CVS, une pour un serveur racoon et une pour un
problème IPv6).
Ceci dit, même si notre administrateur doit installer tous les jours une mise à
jour de tous les programmes de toutes les machines, ce n'est pas génant pour
autant. Un sysème de mise à jour classique commence par:
1 récupérer tous les fichiers d'install dans un endroit particulier
(/var/cache/apt/archives sous debian);
2 il fait l'install.
Si on place un reboot entre 1 et 2, je ne vois pas le problème. Biensûr, l'admin
peut vouloir avoir un minimum d'accès réseau pendant la phase d'install. À la
limite pourquoi pas. Il place des règles iptables (ou autres) super violentes qui
interdisent tout sauf un accès très contrôlé depuis un endroit précis et ces
règles sont relachées après que le système ait perdu les droits d'écriture sur
les binaires. C'est pas plus long.
Puisque c'est du latex, il devient vraissemblable que
ce soit le problème dont je parle.
Un gros avantage de latex est qu'il fait la césure automatiquement.
Cependant, pour que cela marche, il ne faut pas qu'il y ait de macros
dans le mot. Cela ne pose pas de problème en anglais mais en francais,
tous les caractères accentués sont des macros. L'algorithme de césure
ne fonctionne pas pour eux. Pour régler ce problème, il faut utiliser une
police type 1.
\usepackage[T1]{fontenc}
Mais on se retrouve avec une version bitmap de la police. Ce n'est pas
génant sauf quand on veut générer du pdf et le regarder avec acrobat
reader. Celui-ci merde et affiche du texte tout pixelisé pas beau. La version
imprimée est normale.
Pour faire plaisir à acrobat, il faut utiliser une police type1 vectorielle.
Pour cela, on peut faire
\usepackage{lmodern}
Le package lmodern fournit une version vectorielle des polices computer
modern. Avec ça, acrobat reader est content. Cependant, toutes les
versions des polices ne sont pas gérée. Genre le smallcap-sans serif
et d'autres. Ce n'est pas fondamentalement génant.
Au final, quand j'écris du latex en français, mon entête de base est:
Un problème connu est qu'acrobat reader ne SAIS pas afficher
certaines polices bitmap. Entre autre, un ps2pdf sur un postscript
pondu par latex donne quelque chose d'affreux. En revanche, la
version imprimée est complètement normale.
Non je ne me bas pas contre des moulins à vents.
Je n'ai pas envie de me battre.
J'ai appris (maths à l'appuis) que « la foule » n'est pas cohérente.
Donc essayer de montrer à une foule ses incohérence est voué
à l'échec. La seule façon de faire avancer le schmilblic est de
montrer aux personnes leurs incohérences: genre un gars qui
explique que linux c'est génial, c'est peu gourmand en mémoire
et qui deux semaines plus tard explique que c'est normal que
gnome/kde ne soit pas suffisamment légé pour tourner de façon
fluide sur un pentium 1 car ils font plein de trucs et de toute façon,
les gens n'utilisent plus de pentium 1, la norme, c'est des PIII au
minimum.
Je n'ai pas envie de vivre avec un bloc-note pour noter tout ce que
dit machin ou bidule et je n'ai pas assez de mémoire.
C'est juste que « la foule » me semble dire des conneries et là, je
me faisais chier alors j'ai fait un résumé d'une partie des bétises
qu'elle semble dire.
[^] # Re: Bof, pas convaincu par l'article
Posté par fmaz fmaz . En réponse à la dépêche Il n'y a pas que le traitement de texte pour manipuler du texte !. Évalué à 2.
\usepackage[francais]{babel}
Au dire de certains, c'est un petit peu moins bien mais franchement...
[^] # Re: Alternative
Posté par fmaz fmaz . En réponse au journal Avec Ze Gimp 2.2 pre2 pour Windows, je pourrai enfin.... Évalué à 4.
> monsieur ou madame tout le monde utilise The gimp pour retoucher ses
> photos il faut que le plugin red-eye soit ameliore.
Mais qui t'a dit qu'on voulait que monsieur et madame tout le monde utilise
The gimp? En ce qui me concerne, j'ai installé ce programme pour essayer et
je l'ai tout de suite viré: trop compliqué. J'ai des besoins simples. Je veux
pouvoir faire tourner une photo de 90 degrés pour qu'elle soit dans le bon
sens. Je veux pouvoir faire un peu joujou avec la balance des couleurs et
avec le contraste pour compenser le fait que je ne sais pas me servir d'un
appareil photo. Je veux virer des yeux rouges. Pas plus.
Pour mes besoins, The gimp est une usine à gaz incompréhensible et
j'imagine que c'est aussi le cas de monsieur et madame tout le monde.
Biensûr, si monsieur et madame tout le monde s'intéresse vraiment à la
retouche photo, grand bien leur fasse. Il comprendront alors aisément que
ce genre d'activité ne s'improvise pas et qu'il faut du temps pour maitriser
un outil comme The gimp (ou photoshop). Et une fois cette phase
d'apprentissage finie, ils sauront virer des yeux rouges en trois cliques sans
pluggin spécifique.
Frédéric
[^] # Re: Gruik ou propre ?
Posté par fmaz fmaz . En réponse au message gnome et enlightenment. Évalué à 2.
Pour changer le gestionnaire de fenêtre sous gnome, il
faut modifier la clef GCONF
desktop.gnome.applications.window_manager.default
# Projet Gutenberg
Posté par fmaz fmaz . En réponse au journal Encyclopédie de la littérature sous Mandrake. Évalué à 3.
J'ai déjà quelques bouquins sur ma machine grace au projet
Gutenberg (ce sont des fous). Je viens de vérifier, il y a des
textes dans cette encyclopédie que je n'ai pas trouvé sur
Gutenberg. L'inverse est bien évidemment vrai.
Voici donc mes questions:
1. Sous quelles licences sont distribués ces textes?
2. Quel est le format précis de la base de donnée? Ça, c'est pour convertir
les oeuvres Gutenberg que j'aime pour pouvoir tout centraliser.
3. Serait-il possible de fournir au projet Gutenberg les textes qu'ils n'ont pas?
Pour ce qui est du 2., si le format n'est pas trop tordu, il doit même
être possible de faire un script de conversion enclitt <-> Gutenberg
Frédéric
Pour la ref. http://www.gutenberg.org(...)
# Question à la con
Posté par fmaz fmaz . En réponse au message Cluster OpenMosix. Évalué à -1.
Parce que bon, si ça marchait avec openBSD...
Comme on dit:« If it is not broken, do not fix it! »
[^] # Re: D'accord mais pas tout à fait non plus
Posté par fmaz fmaz . En réponse à la dépêche Pas de Windows ? Alors pas d'ordinateur !. Évalué à 3.
J'avais lu sur linuxfr une comparaison très parlante.
Imagine que tu achètes un magnétoscope et on te vend avec "Independance day".
Toi, tu n'aimes pas "independance day". Tu vas voir le marchant et tu lui expliques
que tu veux le magnétoscope sans la cassette vidéo. Et lui de te répondre qu'un
magnétoscope sans cassette vidéo, ça ne sert à rien.
# A propos du journalisme
Posté par fmaz fmaz . En réponse au journal Wikipédia dans Libé. Évalué à 3.
- Informer;
- Commenter l'information.
La seconde partie me semble au moins aussi importante que la première.
Or pour commenter, il faut faire des choix. Par exemple, le projet de
constitution européenne. Le texte fait quelques centaines de pages si on
compte les annexes. Je ne pense pas qu'on puisse objectivement résumer
cette constitution en une centaines de lignes sans être partisant. Il est
normal qu'un journaliste soit partisant mais la nature de kiwipedia/kiwibidule
me semble incompatible avec cela.
Je pense donc qu'un système de journalisme communautaire ne peut pas
surpasser un bon journaliste. Ceci-dit, tous les journalistes ne sont pas de
bons journalistes et trop souvent, les articles que je lis ressemble aux nouvelles
de l'AFP en un peu délayé.
[^] # Re: Amoxiciline
Posté par fmaz fmaz . En réponse au journal Patrick Volkerding est malade. Évalué à 7.
Je me permets de préciser pourquoi ça ne sert à rien, on ne sait jamais.
Un antibiotique s'attaque à des microbes. Ceux-ci sont des être vivants
qui peuvent se reproduire seuls.
Un virus n'est pas un être vivant. Il se reproduit en parasitant des cellules
qui se mettent à pondre du virus. Un antibiotique n'a donc aucun effet sur
un virus et comme un rhume, c'est causé par un virus...
[^] # Re: Bof
Posté par fmaz fmaz . En réponse au journal Espoir, quand tu nous tiens!. Évalué à 2.
Je m'explique. Il y a des choses que l'on peut déployer partout facilement (W^X
et autres joyeusetés). Ensuite, une politique de sécurité passe par définir ce que
les personnes/processus doivent pouvoir faire (tout le reste étant interdit).
Je trouve que les distributions (dans leur grande majorité) ne semblent pas
s'impliquer activement dans ce genre de politique volontariste. W^X, execshield
et autres ne sont pas la norme. De plus, en ce qui concerne la sécurité, il y a
des gens qui développent des outils (SELinux, grsec...). À d'autres de les utiliser.
Il ne me semblerait pas abérant que /home soit monté par défaut en /noexec.
Pour une machine de bureau, soit l'utiliseur est root, soit il n'a pas à installer
de programmes. Dans le cas contraire, la machine est administrée et libre à
celui-ci de changer le ligne correspondante dans le fstab. Or, ce n'est pas le cas.
Apt-get (et j'imagine urpmi) n'authentifient pas par défaut les serveurs et les
paquets qu'ils installent. À la limite debian a un fonctionnement
ultra-conservateur ce qui peut expliquer cela mais redhat peut imposer ce
genre de choses. Et si c'est effectivement intégré aux outils, les gens l'auront
rien à faire de plus.
Une vraie politique forte de sécurité est forcément intrusive mais je pense qu'il
reste des choses à faire qui ne sont pas trop contraignantes pour améliorer
globale d'une distribution.
Frédéric
[^] # Re: Bof
Posté par fmaz fmaz . En réponse au journal Espoir, quand tu nous tiens!. Évalué à 2.
je continue à trouver ton premier commentaire un poil agressif mais ton second
me plait pas mal. Comme tu l'as noté, il y a un certain nombre de choses qui se
font pour sécuriser une machine Linux (SELinux, grsec, pax...)
Et la mise à jour d'un système reste une partie délicate.
Au final, ce que je propose n'est rien d'autre qu'une façon violente de gérer ce
problème de mise à jour.
Un utilisateur technophile a plus de chances d'avoir un comportement sain
vis-à-vis de la sécurité informatique (ne pas rester toujours en root, ne pas
ouvrir tous les mails bizarre...). Cependant, un certain nombre de distributions
visent directement un utilisateur moins « chevronné ». Celui-ci doit être éduqué
mais il me semble plus important d'avoir une politique plus volontaire concernant
la sécurité pour ces personnes. Il me semble que les outils de sécurité mentionné
peuvent être déployé sans trop géner l'utilisateur. Or, à ma connaissance, ils
restent confiné à des niches de spécialites.
Je trouve cela dommage car si pour le moment, Linux n'est pas une cible
importante pour les virus et autres spyware, il est en train de le devenir et si
les éditeurs ne font rien, les machines Linux vulnérables qui se baladent dans
la nature vont finir par devenir un problème.
[^] # Re: Cas d'utilisation
Posté par fmaz fmaz . En réponse au journal Espoir, quand tu nous tiens!. Évalué à 2.
Heuuu...
Non.
La seule raison pour laquelle j'ai mentionné OSX est que c'est le premier
unix orienté desktop dont j'ai entendu parlé qui s'arrange pour « virer »
root. Et je trouve que c'est bien.
[^] # Re: Bof
Posté par fmaz fmaz . En réponse au journal Espoir, quand tu nous tiens!. Évalué à 2.
:) Ça rejoint ce que je disais pour les virus de macro.
Si son fichier à les droits en exécution, c'est un exécutable et il est traité
comme tel. Sinon, il faut faire
# perl virus
et là, pour augmenter la sécurité, il faut changer l'utilisateur. Je suis bien
convaincu que le fishing et autres techniques de social engenering sont
applicable mais c'est autre chose.
Oui, ce que je veux, c'est du SELinux ou autre et oui encore, le
problème se pose quand on fait une mise à jour.
Si on arrive a mettre en place un système de clef, de sertificat ou autre, on peut
être à peut près sûr de faire une mise à jour depuis le bon site. Évidemment, si
le site est compromis, on est eu.
Au moment où on fait l'installation, la machine est plus vulnérable car on doit
authoriser certaines opérations dangereuses (écrire sur le disque). L'idée est
donc de passer temporairement dans un environnement beaucoup plus contraint
(sans réseau, sans serveur d'impréssion, éventuellement sans serveur
graphique). Une telle configuration n'est certe pas viable en utilisation courante
mais juste pour une installation de programmes, cela me paraît convenir.
Et je vois mal comment une attaque réseau peut être réalisée si
- le système est sain;
- les fichiers à installer sont authentifiés;
- aucune communication avec l'extérieur n'est possible.
Biensur il reste possible de modifier les fichiers de configuration qui se trouvent
dans /etc. Mais il y a rarement une option « installer une backdoor »
configurable dans /etc dans les programmes normaux.
[^] # Re: Bof
Posté par fmaz fmaz . En réponse au journal Espoir, quand tu nous tiens!. Évalué à 1.
Je sais bien que la sécurité absolue, ça n'existe pas, je sais bien qu'il y aura
toujours des trous de sécurité. Je sais bien qu'on ne peut pas être sûr que les
mesures de sécurité mises en place ne seront pas détournée.
Ce que je cherche, ce n'est pas la sécurité absolue: la sécurité informatique
absolue, c'est de ne pas avoir d'ordinateur. Ce que je cherche, c'est comment
microsoft, apple ou redhat peut s'arranger pour rendre son système plus sûr
de façon notable sans faire chier le client. Car la sécurité, c'est avant tout
quelque chose de chiant et de pénible car c'est avant tout quelque chose qui
contrôle et qui interdit.
Je pars du constat qu'une machine windows non administrée se retrouve vite
bourrée de spywares, virii et autres. Si on excepte les virus de macro et les
chevaux de troye, ce genre de chose existe parce que du code à pu s'exécuter
sans que cela ait été voulu. Pour se protéger de ce genre de chose, il faut donc
éviter qu'un bug puisse conduire à l'execution arbitraire de code. Une première
approche consiste à empêcher cette exécution très tôt (W^X, malloc
randomisé, etc...). Maix comme tu le dis si bien, il se peut qu'un attaquant
arrive quand-même à faire exécuter son programme. Or l'une des premières
choses que l'attaquant va essayer de faire, c'est rendre cet exécution pérène.
Si un simple reboot permet de virer tous les spywares et tous les virus,
l'attaquant n'a pas gagné grand chose. Pour péréniser son attaque, il doit
pouvoir écrire sur le disque des informations. De plus, ces informations doivent
être exécutée de façon automatique. Ce que je propose a pour but de rendre
cette seconde étape plus difficile.
Si toutes les partitions sur lequel un utilisateur peut écrire sont montées en
noexec, c'est déjà un premier pas. Cependant, comme l'attaquant est fourbe,
il va trouver une faille de sécurité et arriver à devenir root. Dans ce cas, il
peut écrire dans /etc/rc2.d pour que son truc se lance au démarrage. Si
on s'arrange pour que root ne puisse pas écrire dans /bin /sbin /usr /lib...
et qu'un programme doive faire partir d'un de ces répertoires pour être lancé,
la tâche de l'attaquant devient plus dur: il doit trouver le moyen pour rendre
à root les droits d'écriture aux endroits ou il ne les a plus.
Evidemment, ce n'est pas complètement sûr mais ça complique la tâche de
l'attaquant.
[^] # Re: de l'idée a la realisation
Posté par fmaz fmaz . En réponse au journal Espoir, quand tu nous tiens!. Évalué à 2.
(http://www.openbsd.org/cgi-bin/man.cgi?query=securelevel&apropo(...))
En niveau 1, on peut placer un flag immutable sur des fichiers et la seule façon
de pouvoir à nouveau ecrire sur ces fichiers est de rebooter.
Je ne sais pas si linux permet ce genre de chose mais j'imagine qu'il existe des
patch pour faire des choses semblables.
[^] # Re: Cas d'utilisation
Posté par fmaz fmaz . En réponse au journal Espoir, quand tu nous tiens!. Évalué à 2.
Le terme rook-kit était mal choisi.
À priori, ce genre de technique empèche un spyware de s'installer sans l'accord
explicite de l'utilisateur. Il faut que le spyware ailles se copier dans la zone
d'installation, attendes le reboot et à ce moment, il faut que l'utilisateur accepte
d'installer un programme qu'il n'a pas demandé.
De plus, si le système n'accepte d'exécuter que des binaires venant de la
partition « binaires », cela empêche aussi le spyware de se placer dans le
/home et de modifier le .xsession (ou autre technique de ce genre).
Cela n'empêche pas les chevaux de troie ni les virus de macro et cela ne garantit
pas l'intégrité des données de /home mais c'est une protection beaucoup plus
importante.
Je ne dis pas que ma technique est l'arme ultime mais que c'est une façon pas
trop intrusive d'augmenter de façon importante la sécurité. De ce point de vue,
demander à l'utilisateur de faire des mises à jours toutes les semaines est plus
contraignant, même s'il vaut mieux le faire. De plus, certaines personnes n'ont
pas encore l'ADSL et sur un modem RTC, les mises à jours...
# hop la
Posté par fmaz fmaz . En réponse au message configuration du clavier pour LaTeX. Évalué à 2.
Don't turn to the dark side.
Use emacs Luck!
\end{provoque}
Ceci dit, auctex est vraiment pas mal pour faire du latex.
[^] # Re: Eviter les mots de passe triviaux
Posté par fmaz fmaz . En réponse au journal FAI et mots de passe. Évalué à 5.
d'un symbole de ponctuation et de majuscule.
Me9do!r
ne me semble pas un si mauvais mot de passe. Après, comme j'imagine que
personne ne change son mot de passe, ça ne doit même pas leur coüter trop cher
de faire une petite vérification par dictionnaire.
[^] # Re: Redémarrer à chaque make install???
Posté par fmaz fmaz . En réponse au message Vive la paranoïa. Évalué à -1.
les soirs soit rebooté de temps en temps pour faire une mise à jour système
ne me choque pas.
Désolé.
[^] # Re: Root non valide
Posté par fmaz fmaz . En réponse au message Vive la paranoïa. Évalué à 4.
Rien ne t'empêche de renommer root en zorglub. Globalement, ça marchera pareil
sauf que certains programmes ont "root" codé en dur.
Ensuite, la méthode OSX est de déactiver le passwd root et de mettre un
utilisateur "admin" en sudoer. Par exemle le fichier sudoers suivant donne tous
les droits à zorglub. La dernière ligne est faire pour qu'il faille TOUJOURS donner
le passwd.
User_Alias ADMIN = zorglub
ADMIN ALL= PASSWD: ALL
Defaults timestamp_timeout=0
Ensuite, on utilise un utilisateur normal pour l'utilisation normale.
[^] # Re: Redémarrer à chaque make install???
Posté par fmaz fmaz . En réponse au message Vive la paranoïa. Évalué à 2.
rebooter.
Pour la machine de beau papa qui installe 2 programmes par an et qui éteind
religieusement sa machine tout les soirs, ce n'est pas deux reboots de plus qui
vont l'embêter. Or, il est important de sécuriser aussi la machine de beau papa.
L'administrateur qui gère 3000 machines ne va pas s'amuser à changer la
configuration des 3000 machines tous les jours. Il va se contenter de faire les
mises à jours de sécurité (ce qui demande déjà pas mal de boulot) et il va
administrer son réseau. S'il n'est pas con, il va aussi s'arranger pour avoir le
moins de boulot possible. Il ne va donc pas installer apache sur la machine d'une
secrétaire. Idéalement, il y aura un gros serveur d'application avec des clients
légés. Dans ces deux cas, l'immense majorité des machines n'auront que peu
de programmes différents d'installés et donc le nombre de mises à jours de
sécurité sera faible (en 2004, il y a eu 9 security/advisories pour netBSD dont
une pour ftpd, une pour CVS, une pour un serveur racoon et une pour un
problème IPv6).
Ceci dit, même si notre administrateur doit installer tous les jours une mise à
jour de tous les programmes de toutes les machines, ce n'est pas génant pour
autant. Un sysème de mise à jour classique commence par:
1 récupérer tous les fichiers d'install dans un endroit particulier
(/var/cache/apt/archives sous debian);
2 il fait l'install.
Si on place un reboot entre 1 et 2, je ne vois pas le problème. Biensûr, l'admin
peut vouloir avoir un minimum d'accès réseau pendant la phase d'install. À la
limite pourquoi pas. Il place des règles iptables (ou autres) super violentes qui
interdisent tout sauf un accès très contrôlé depuis un endroit précis et ces
règles sont relachées après que le système ait perdu les droits d'écriture sur
les binaires. C'est pas plus long.
[^] # Re: Attention
Posté par fmaz fmaz . En réponse au message Pb impression PDF. Évalué à 3.
Puisque c'est du latex, il devient vraissemblable que
ce soit le problème dont je parle.
Un gros avantage de latex est qu'il fait la césure automatiquement.
Cependant, pour que cela marche, il ne faut pas qu'il y ait de macros
dans le mot. Cela ne pose pas de problème en anglais mais en francais,
tous les caractères accentués sont des macros. L'algorithme de césure
ne fonctionne pas pour eux. Pour régler ce problème, il faut utiliser une
police type 1.
\usepackage[T1]{fontenc}
Mais on se retrouve avec une version bitmap de la police. Ce n'est pas
génant sauf quand on veut générer du pdf et le regarder avec acrobat
reader. Celui-ci merde et affiche du texte tout pixelisé pas beau. La version
imprimée est normale.
Pour faire plaisir à acrobat, il faut utiliser une police type1 vectorielle.
Pour cela, on peut faire
\usepackage{lmodern}
Le package lmodern fournit une version vectorielle des polices computer
modern. Avec ça, acrobat reader est content. Cependant, toutes les
versions des polices ne sont pas gérée. Genre le smallcap-sans serif
et d'autres. Ce n'est pas fondamentalement génant.
Au final, quand j'écris du latex en français, mon entête de base est:
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\usepackage[francais]{babel}
Frédéric
# Attention
Posté par fmaz fmaz . En réponse au message Pb impression PDF. Évalué à 2.
Un problème connu est qu'acrobat reader ne SAIS pas afficher
certaines polices bitmap. Entre autre, un ps2pdf sur un postscript
pondu par latex donne quelque chose d'affreux. En revanche, la
version imprimée est complètement normale.
[^] # Re: Dites les gens.
Posté par fmaz fmaz . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 2.
Je n'ai pas envie de me battre.
J'ai appris (maths à l'appuis) que « la foule » n'est pas cohérente.
Donc essayer de montrer à une foule ses incohérence est voué
à l'échec. La seule façon de faire avancer le schmilblic est de
montrer aux personnes leurs incohérences: genre un gars qui
explique que linux c'est génial, c'est peu gourmand en mémoire
et qui deux semaines plus tard explique que c'est normal que
gnome/kde ne soit pas suffisamment légé pour tourner de façon
fluide sur un pentium 1 car ils font plein de trucs et de toute façon,
les gens n'utilisent plus de pentium 1, la norme, c'est des PIII au
minimum.
Je n'ai pas envie de vivre avec un bloc-note pour noter tout ce que
dit machin ou bidule et je n'ai pas assez de mémoire.
C'est juste que « la foule » me semble dire des conneries et là, je
me faisais chier alors j'ai fait un résumé d'une partie des bétises
qu'elle semble dire.
Voilà.
[^] # Re: Et l'aspect ludique
Posté par fmaz fmaz . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 4.
[^] # Re: Dites les gens.
Posté par fmaz fmaz . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 1.
Franchement...
NON