PLuG a écrit 1006 commentaires

D'ailleur en interne ils ont une distribution IBM a base de redhat disponible pour installer sur leurs thinkpads.
au menu des logos IBM de partout, un kde bien paramétré (a ce qu'il parait, je l'ai vu mais pas essayé) et des packages RPM avec Notes (messagerie interne) et MSOffice, les deux grace à Wine.
Domage, ils avaient aussi OpenOffice mais maintenant que le package MSOffice se répand ils re-basculent tous vers cette solution :-(

Quoi qu'il en soit, c'est une belle démarche qui permet aux unixiens (AIX ...) de bosser avec un portable sous unix (linux) et de se sentir comme chez soit.

Il suffit de bien expliquer aux gens que les emails sont aussi securisés que les cartes postales envoyées sans enveloppe : tout les facteurs sur la route peuvent les lire.

l'analogie email/courrier est AMHA moins bonne que email/carte postale.

Sympa mais ce n'est pas du tout conforme a la RFC ODMR.

avec ODRM, le client se connecte sur le port tcp/366 du serveur SMTP et s'authentifie.
le serveur SMTP commence alors a relayer le mail en SMTP normal DANS LA MEME CONNECTION TCP, ce qui est assez sympa a travers un firewall statefull ...

la RFC existe, le client existe (fetchmail), il doit bien exister un serveur opensource quelque part !!

d'après redhat, la faille est difficile à exploiter
c'est marrant dans l' annonce de redhat sur bugtrack il n'y a rien de tel,
et meme pire, redhat annonce qu'il y a un "proof of concept" mais qu'il
n'a pas été diffusé ...

bref exactement l'inverse de ce qui est écrit dans ton post ?!?

t'as des liens ?
je vais verifier mais je n'ai pas vu de ODMR dans postfix et qmail.

Je cherche un serveur SMTP capable de faire de l'ODMR (rfc2645).
Je n'ai trouvé qu"un truc qui tourne en companie de sendmail, et c'est seulement dans les wish list des autres ...

quelqu'un pour me conseiller ?

Humm premiere distrib commerciale ?
en tout cas j'ai commencé avec la SLS et tu m'as mis un doute sur leurs dates de parution, alors google group et sa fonction de remontage dans le temps m'a rassuré:

la slackware est apparue le 18/07/1993, d'une SLS 1.02 déjà bien implantée.
ouf !

la SLS a été annoncée le 12/08/1992, quasiement un an avant.
Le post l'annoncant a failli se transformer en troll car la SLS etait disponible a la vente (Du commercial sur comp.os.linux !!) ...
je reproduit ici un morceau du message, nostalgie ....

This distribution is different primarily because it has an initial
install program, it breaks everything into packages, which can be
stored on DOS floppies, meaning disk images don't have to be posted
(except for the boot and utils disks), and because it has a menu
driven sysadmin program.

Following is the readme file from the distribution.
-------------------------------------------------------------------
Here is release .96c of the SoftLanding Linux System (SLS),
which is NOT just an image dump of someones Unix system.
...


et a la fin du message:

The SLS system is available, primarily for non-netters from:

Softlanding Software
910 Lodge Ave.
Victoria, B.C., Canada
V8X-3A8
(604) 360-0188

for $3.25/disk US ($4.00/disk Canadian) copying charge.

Softlanding: The DOS Bailout Specialists.

Si il peut y avoir un rapport.
Un equipement qui filtre doit parser des regles de filtrage, ce qui prend plus ou moins de temps ... surtout si elles ont ete codées avec les pieds.
le simple fait d'intercaler un equipement de plus pour filtrer peut changer le ping.

Et heureusement !!!
La mutualisation (le surbooking) a du bon, c'est grace a lui qu'on arrive a 30€/mois pour l'ADSL. Comparez le prix avec des fournitures de bande passante garantie ... c'est loin d'etre abordable pour le grand public !!

Merci ! je ne connaissais pas.

a noter par rapport a IPSEC, (et IKE ) la renégociation des clefs est ... comment dire ... beaucoup plus faible.
les vecteurs IV sont simplement incrémentés, on connait la version "en clair" de plusieurs parties du message chiffré (en particulier un octet toujours a zéro pour faciliter le repérage des mauvaises clefs !!).

a priori, IANAC comme il dit mais c'est beaucoup plus faible qu'une bonne implementation IPSEC+IKE avec un re-keying régulier, meme si ca profite déjà du tout nouveau algo AES.

mais ca a l'air tellement simple a mettre en place !!
faudra que j'essaye, en complement a WEP ...

sous linux, tu peux assez facilement:
1/ utiliser iptables pour filtrer les cartes wifi sur l'adresse MAC (c'est pas du tout fiable mais c'est gratuit ... iptables)
2/ utiliser freeswan (ou le support IPSEC inclu au noyau 2.5) pour authentifier et encrypter les communications IP.
3/ de nouveau utiliser iptables pour n'accepter via eth0 que le traffic esp/udp 500 qui est necessaire pour freeswan.

cela authentifie les machines (et non pas les personnes), et assure un niveau de chiffrement assez elevé. Pour le type qui commence son attaque depuis la rue ca met le ticket d'entree sur le réseau un poil haut tout de meme.

NB: évidement ces restrictions sont a faire sur l'access-point (sous linux) mais AUSSI SUR CHAQUE CLIENT (sinon depuis la rue on peut attaquer un client et se servir de son tunnel IPSEC pour entrer ... )

L'idée c'est d'utiliser EAP-TLS.
http://www.missl.cs.umd.edu/wireless/eaptls/(...)

Une remarque cependant: de source interne a CISCO, il semble que leur implementation du WEP n'a JAMAIS ete sujette aux vecteurs d'initialisation faibles. De leur propre aveu, ce n'etait pas grace a un visionnaire chez eux mais plutot a un bug qui ecartait involontairement certains IV (dont les faibles).
Il faut bien que les "bugs" aient de bon coté aussi ...

Je n'arrive pas a croire que j'ai pu écrire une telle connerie ci dessus.
Effectivement sous linux c'etait notablement plus rapide, mais je n'aurai pas du donner de chiffres (je ne m'en souviens pas), surtout 200% c'est ridicule. mea culpa.

Juste une remarque, FAM sous linux n'est qu'un daemon porté de SGI vers LINUX par SGI et redhat. La notification au niveau de l'OS (dans le noyau quoi) s'appellait FAM également chez SGI mais s'appelle dnotify dans notre kernel préféré. l'historique c'est que SGI avait proposé la fonctionnalité en l'appelant FAM, l'idée a plus aux dev linux mais pas le code, aussi ils ont codé la même feature a leur sauce ==> dnotify.

mes 2 cents

exact. sur PC entre les IRQ et les limites du DMA, y a du boulot avant de passer a 64bit le biniou !!

En tant que root le virus peut faire tout et n'importe quoi, quelques exemples:
- supprimer les partitions windows de ton disque,
- detruire ton ecran en changeant la configuration de Xfree,
- rendre ton processeur fou en changeant le microcode ( /dev/cpu/0/microcode rigolo mais ne survi pas au reboot),
- detruire ton cpu/tes disques en empechant les ventilo de tourner (apm),
- et pourquoi pas flasher ton bios.

toujours pas convaincu de la différence ?

pour finir, tout faire tourner avec les droits root, c'est faire tourner le virus forcement avec tous les droits, ce qui rend son ecriture beaucoup plus facile.

Où est le temps ou on ecrivait les virus en assembleur pour qu'ils soient furtifs et tiennent dans moins de 200 octets ?
Ce temps est révolu.
De nos jours les virus sont triviaux et font des centaines de Ko non pas par necessité, mais par facilité: a quoi bon planquer le code puisqu'il suffit de l'accompagner d'un message "cliquez moi pour voir !" pour infecter toute la planette. Les virus d'aujourd'hui sont écrits par des script-kiddies simplement parce que la plupart des utilisateurs leur simplifient la vie. Ils les execute en faisant exprès, ils utilisent des comptes privilégiés parce que c'est plus facile et ils ne mettent pas a jour leur système parce que c'est contraignant.

Alors oui, nous verrons bientot des virus sous linux. Dès que ce genre d'utilisateur se penchera sur notre OS favori. Mais les anti-virus je ne suis pas sur, le message sera simple: ne rien faire en tant que root, upgrader le plus souvent possible ...
A noter d'ailleur que les utilisateurs qui ne maintiennent pas leur système a jour ne maintiennent pas NON PLUS leur anti-virus a jour .... bref c'est pour bientot.

system("rm -rf /*");


ah ca c'est de la programmation système alors ;-)

ok --> []

De plus si le but de la NSA est d'utiliser des trous de sécurité avant tout le monde, elle n'a pas besoin de participer au developpement pour cela, le code source est, comment dire, assez accessible il me semble ;-)
Donc dans le fait qu'elle participe j'y vois plutot du bien.

Juste une question, as tu une idée du rapport de performance de la meme appli entre ORACLE sur NT et ORACLE sur redhat ?

Il y a 3 ou 4 ans, on avait fait faire le test pour rire a un consultant oracle (bossant en direct pour oracle), et sur l'appli testée on avait un rapport 2 sur quasiement toutes les requetes ... en faveur de linux bien sur ;-))
meme hardware, meme datas, meme version d'oracle... et meme appli.

On peut le voir comme ca, mais l'astuce c'est que tu code TOUJOURS avec un echo devant et que tu n'as pas besoin de l'enlever quand tui es sur du resultat puisque - si tu lis jusqu'a la fin de mon message - tu pipe le tout dans un autre shell (astuce).

en clair, au premier lancement tu te retrouve avec
#/tmp/monshell.sh
rm /tmp/pipo1
rm /tmp/pipo2
mv /tmp/pipo1.gif /tmp/pipo3.txt

si ca te plait , tu le lance en demandant d'effectuer les operations avec un pipe comme ca:
#/tmp/monshell.sh | /bin/sh

capté ?

Oracle gere les raw devices c'est sûr.
Mais de moins en moins d'installations d'oracle se servent de cette "feature".

A une certaine époque, les filesystemes etaient LENTS, un accès raw-device se justifiait.
De nos jours, les filesystèmes sont très rapides, la différence est quasiement invisible, en pratique si la bdd ne tiens pas la charge avec un accès filesystème, passer en raw-device ne changera rien, et surtout montre que les futures évolutions du besoin (montée en charge progressive) ne pourront de toute manière pas être pris en compte.
Si la tenue en charge passe par un accès en raw-device, il est préférable dès aujourd'hui de charger d'architecture (ou de hardware, ou les deux) plutot que d'hypothéquer a ce point les évolutions futures du système mis en place.

Voila, c'est mon avis, je le partage... avec beaucoup d'admin oracle d'ailleur !!

Tres interessant, je n'étais pas au courant.

Il faudrait voir le status actuel, dump/restore est quand meme livré de base avec RedHat par exemple, qui plus est en version "linké en statique" pour etre sur de son fonctionnement... Et il a été relivré bien APRES ce message qui date quand meme de 2001 !!

Dans le changelog de dump, on peut voir que le 12/09/2001 ils ont ajouté un ioctl pour flusher le buffer/page cache du kernel ...
c'est peut-etre la réponse au probleme.

Pourquoi ne pas autoriser les moderateurs a passer les journaux interessants sous forme de news ?

C'est EXACTEMENT ce que fait restore en mode interactif !!
jette un oeuil a dump/restore ...