KDE tuera Windows

In article <56sa17-l392.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:

Yves Lambert a perdu son temps a nous dire:

Oui bon, après réflexion, je ne suis plus tout à fait d'accord avec PK et
SC, mais j'ai mieux compris le souci. Si tu as une machine compromlise
sur le réseau, et qu'elle dispose d'une chaine de compilation complète,
celle ci peut etre utilisée pour installer le rootkit le plus vicieux,
une bombe ou tout autre malware, alors que si ce n'est pas le cas,
l'attaquant resterait dans son rootjail et ne peut rien faire d'autre
que ce que tu lui permet. Ce n'est pas le code du logiciel qui est en
jeu, mais le fait de le compiler sur le serveur de prod (et donc que
celui ci embarque make, gcc et wget)

Tu m'expliques qu'est ce qui interdit de faire un rootkit avec un
binaire statique deja importe d'une autre machine ?

Tu ne peux pas faire un break-jail en static. Il faut chopper la bonne
bibliothèque en suid. Et c'est de la responsabilité de l'admin, mais tu
peux avoir absolument besoin du suid. Le suid est toujours utilisable
pour escalader mais peut aussi etre très utile, voire indispensable pour
autre chose.

ou meme en Perl, en
bash ou en whatever.

Et comment tu fais le breakjail ? Comment tu fais l'escalade de
privilège ?

Faire tourner un programme n'est pas vraiment un probleme sur Unix, pas
besoin d'un compilo pour ca.

Il n'est pas question de le faire tourner mais de le linker avec une
bibliothèque vulnérable qui permet une escalade de privilège puis de
le faire tourner. Explique comment tu fais sans compiler ?

--
http://mikeread.tripod.com/archive.htm

In article <pdsa17-l392.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:

Yves Lambert a perdu son temps a nous dire:

ça ne répond toujours pas à ma question : pourquoi c'est MAL de mettre un spamd
sur le mx frontal (qu'il tourne en socket unix ou en socket tcp, sur le
serveur de mail ou une autre machine n'entre pas en jeu dans la
question) et que ce soit postfix ou exim4 ne change strictement rien au
problème puisque les deux le permettent. Je n'y vois que des avantages
(à part le temps machine). Je ne sais pas qui a dit que c'était mal,
qu'il se dénonce et m'explique pourquoi.

Ce n'est pas une question de mettre le process spamd sur le serveur
physique qui est frontal ou sur n'importe quel autre serveur. Le point
est ou est-ce qu'on traite l'email avec l'anti-spam.

Si tu les traites par le smtpd, en cas d'attaque violente, tu vas te
retrouver avec 120 process de spamd et un serveur par terre.

C'est là que le greylisting intervient. Tu désynchronise. Un DOS n'a pas
besoin d'un spamd qui tourne. Meme si le serveur est hyper léger,
threadé, ça se joueau niveau TCP. Après tu peux toujours déporter
temporellement ou spatialement (si tu as la puissance de calcul).



--
http://mikeread.tripod.com/archive.htm

Yves Lambert a perdu son temps a nous dire:

Tu ne peux pas faire un break-jail en static. Il faut chopper la bonne
bibliothèque en suid. Et c'est de la responsabilité de l'admin, mais tu

Une bibliotheque en suid ?

La je veux bien qu'on m'explique, parce qu'habituellement, je fais un
chmod +s sur un executable, mais pas sur une bibliotheque.

Et comment tu fais le breakjail ? Comment tu fais l'escalade de
privilège ?

Ben, j'aimerais savoir comment tu fais avec un compilateur.



--
http://unices.over-blog.com/ Un Francais en Chine

Yves Lambert a perdu son temps a nous dire:

C'est là que le greylisting intervient. Tu désynchronise. Un DOS n'a pas
besoin d'un spamd qui tourne. Meme si le serveur est hyper léger,

Pas forcement besoin d'un DOS pour se retrouver avec 120 smtpd en
memoire. Parfois, un simple spaming suffit, une mauvaise bande
passante... enfin, il y a plein de raison qui fait que ca peut arriver
et que c'est pas une raison pour lancer 120 spamd.



--
http://unices.over-blog.com/ Un Francais en Chine

Le Mon, 04 Jan 2010 23:12:35 +0100, Vivien MOREAU a écrit:

Slackware *a* un gestionnaire de paquet.

Et slapt-get.

--
There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way
is to make it so complicated that there are no obvious deficiencies. The
first method is far more difficult.
C.A.R. Hoare.

Le 04-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :

In article <slrnhk232f.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:

Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :

In article <fp1617-h7j2.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:

Yves Lambert a perdu son temps a nous dire:

Ces OS plus stables ne tournent pas sur PC ???

Et non, comme quoi a chaque plateforme son OS et a chaque OS sa
plateforme.

Exemple d'OS (on va rester dans l'open source pour ne pas trop se
disperser) qui tourne sur d'hypothétiques machines ultra-stables (tu
n'as pas cité de marque on ne peut faire que des suppositions) qui ne
peut pas etre porté sur un PC ?

Il y a un projet qui consiste à cloner OpenVMS sur PC

Si le projet aboutit je connais quelqu'un que ça interresera.

et qui patine sur
la PAL des machines VAX/Alpha/IA64. Une partie de l'OS est codée en
dur dans un FPGA qui gère les niveaux de privilège. Ces niveaux de
privilèges n'existant pas sur un processeur intel, il te faut émuler
le fonctionnement de ladite PAL en soft, ce qui est loin d'être
trivial.

Ok. Je comprend mieux ce que voulait dire ST, mais il n'a pas été foutu
de donner un seul exemple Open Source. C'est encore d'actualité sur des
machines neuves OS400, Irix, HP/UX etc. ?

C'est encore d'actualité sur les IA64 de Monsieur HP.

Et qu'est-ce qui empecherait
de porter IRIX et HP/UX sur PC si on avait les sources ? Rien, si ?
Quand à OS400 il existe des émulateurs qui tournent sur PC...

Pour les alpha et les vax aussi (simh fait parfaitement tourner
OpenVMS 7.3 et ES40 est maintenant à peu près utilisable). Mais
émuler la PAL en userland, c'est _largement_ plus facile.

Tant que c'est en userland, c'est assez facile. Mais en
mode kernel, c'est beaucoup plus joyeux ;-)

J'imagine, et je vois l'intéret (j'ai travaillé (comme luser, hein, je
n'ai aps fait d'administration système) sur Multics. Aucun Unix
n'atteint la sophistication de la gestion des niveaux de privilège de
Multics. VMS je croyais que c'était très basique à ce niveau là au
contraire. Je connais très mal...

Regarde simplement la liste des droits de VMS. Tu verras comme c'est
simple ;-)

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 04-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :

In article <slrnhk1fvc.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:

J'ai plusieurs programmes qui ne _fonctionnent_ pas sur NetBSD en
raison de bugs spécifiques (sigpending()). Sous FreeBSD, j'ai trouvé
un bug dans sig_info. Sous OpenBSD, il traîne un sombre problème
dans sigaltstack().

La gestion des signaux n'est pas très différente sous *BSD et linux ? Je
pensais que tu parlais de programmes en userland.

La gestion est la même, ce sont les bugs qui sont différents ;-)
Et OpenBSD se permet de modifier des appels parfaitement spécifiés
dans Posix parce que c'est très compliqué de les rendre sûrs (aux
dires de Theo). Ça permet d'avoir des comportements assez amusant de
programmes qui fonctionnent partout sauf sous OpenBSD...

Les logiciels des ports ont été patchés pour
fonctionner malgré ces problèmes (en tout cas, mon NetBSD/sparc32 et
mon FreeBSD/i386 téléchargent les sources puis les patchent). Il ne
me viendrait pas à l'idée d'utiliser autre chose que les logiciels
des ports car le fonctionnement de ceux-ci ont été validés.

Ce que je parlais c'était de patcher un port ou ajiouter un port pour
répondre à un besoin spécifique. Chez toi tu t'en fous, et pour le
valider, ça passe par les développeurs du BSDD sur lequel tuu le fais
(ou si c'(est crade tu ne le propose pas).
1. Utiliser le mécanislme de port pour un logiciel qui n'y est pas ou
patcher le port pour qu'il installe la version qui t(intéresse et qui
n'est pas la version du port ou bien
- éventuellement appliquer des patchs tiers, si tu sais leur utilité (ça
ou des patchs que tu as fait toi, c'est hyper facile du moins avec
NetBSD.

Je me contrefiche de la sécurité de ces machines de test

Là il était plus question de fonctionnalité que de sécurité. Ou alors
j'ai pas suivi le film.

On peut sécuriser de deux façons : sécuriser directement la machine
ou s'arranger pour que ladite machine ne soit pas accessible
sauf au travers de frontaux. C'est pour cela que mes frontaux sont
tous sous Linux autre chose que x86 ou VMS et que mes machines de calcul
tournent sous du Solaris ou du xBSD. Maintenir une debian à jour,
c'est très facile et ça ne provoque que très peu d'indisponibilité.
Idem pour un VMS. Pour un xBSD ou un Solaris, c'est autre chose.

car elles
ne sont pas directement sur le grand ternet (adresses non routables
et derrière des firewall sérieux). Les frontales sont toutes sous
debian avec les patches de sécurité.

LAMP c'est d'un commun :)

Dans mon cas, c'est surtout LAPR (Linux, Apache, PostgreSQL, RPL/2),
voir VWRR (VMS, WASD [le truc qui éclate Apache], RDB, RPL/2) ;-)
J'ai eu tellement de merdes avec MySQL que je refuse d'utiliser ce
truc sur des bases sensibles.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 04-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :

In article <tvu717-e2l2.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:

JKB a perdu son temps a nous dire:

Utiliser exim pour un serveur privé (comprendre une station de
travail qui a besoin d'un serveur de mail pour que certains daemons
puissent envoyer un courrier à l'administrateur en cas de problème),
pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise
tant le truc est troué.

C'est faux. Les failles sont corrigées. ALors que Postfix qui n'a
soi-disant pas eu de problème de sécurité n'a pas eu non plus de patches
de sécurité.

Je ne parlerais pas de postfix. Exim a plusieurs problèmes dont le
fait d'être monolithique, ce qui permet des choses assez
exceptionnelles en terme de performance et de sécurité (failles
potentielles). J'ai retrouvé une machine avec une charge
hallucinante justement parce que exim était monolithique (je ne sais
pas ce qu'il en est actuellement) et essayait de traiter les
messages sans les mettres dans une queue même s'il n'y arrivait plus
en temps réel. Par contre, ça remplissait les logs...

Sur une machine seule dans son coin, pourquoi pas. Sur un vrai gros
MX, j'éviterais, mais chacun choisit son poison.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 05-01-2010, ? propos de
Re: KDE tuera Windows,
Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :

Yves Lambert :

ça ne répond toujours pas à ma question : pourquoi c'est MAL de mettre un spamd
sur le mx frontal (qu'il tourne en socket unix ou en socket tcp, sur le
serveur de mail ou une autre machine n'entre pas en jeu dans la
question) et que ce soit postfix ou exim4 ne change strictement rien au
problème puisque les deux le permettent. Je n'y vois que des avantages
(à part le temps machine). Je ne sais pas qui a dit que c'était mal,
qu'il se dénonce et m'explique pourquoi.

On disait en frontal du smtpd, tu peux le mettre derrière. À la postfix
:
smtpd -> queue ---> spamd ----> boites à lettres
|
+--> smtp (relais)

et non pas smtpd -> spamd -> queue.

déjà si ton spamd tombe tu continues à recevoir les mails, et ce en
continuant à relayer. La réception ne dépend pas de spamd (modulo la
charge induite) et de toutes façons c'est pas utile de vouloir
filtrer ses courriers sortants.

Je ne comprends pas bien. Si le spamd tombe, tu ne reçois plus de
mails ? Chez moi, toujours avec sendmail, si le spamd tombe (ou le
milter associé), sendmail accepte par défaut. Ça me semble plus
logique. Il vaut mieux être pollué durant quelques instants que de
perdre des messages.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 04-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :

In article <slrnhk1f7v.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:

Ta prose est illisible...

C'est possible mais tu ne répond pas à la question : pourquoi c'est mal
de filtrer les messages avec un spamd et donner la réponse 400 après le
.

Tu m'excuseras, mais pour répondre à une question, il faut l'avoir
comprise. Ceci étant dit, je ne vois pas pourquoi renvoyer un 4xx
après le '.'. Personnellement, j'envoie un 5xx à la fin de la
transaction, c'est plus radical.

personnellement je n'y vois que des avantages. Tu m'as expliqué comment
le faire sur postfix, puis comment s'en passer) ma question est «pourquoi
s'en passer ?»; c'est efficace, élégant et ça permet de respecter à la
lettre les RFC concernant le mail, alors que les spams passent au
travers du greylisting, par exemple et que les RBL génèrent trop de
faux positifs.

Le greylisting, ça se configure aux petits oignons avec le score SA
et les RBL sans jamais mettre en liste noire (sauf des trucs
triviaux comme des incohérences SPF).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.