Tu bases ton raisonnement sur le postulat que Xen n'a aucun bug qui permet à une application de prendre le contrôle de l'OS hôte.
Drôle de postulat.
Xen est un logiciel, fait par des humains qui ont pour habitude de faire des bugs dans les logiciels. Pourquoi Xen dérogerait-il à la règle?
Tu nous parles de la couche réseau, on parle depuis le début du code exécutable que tu rajoutes en plus à ta machine, code qui peut être buggé. On s'en fout de la couche réseau, le risque est identique quelque soit la solution.
Tu ajoutes une voie supplémentaire possible pour un attaquant, et tu crois qu'il ne va pas essayer de l'utiliser? Ouvre les yeux, regarde ce que tu fais : tu rajoutes des possibilités d'attaque.
Le pire est que tu peux avoir X applis robustes aux attaques, il en faut une, et une seule, pour que tes applis se fasse trouées dans le cas où une petites faille locale sur Xen arrive.
Donc il faut que tu puisses garantir que aucune de tes X applis n'a de trou de sécurité, ça démultiplie les risques de façon importante.
Tu es prêt à prendre le risque? OK, mais informe quand même tes supérieurs, sinon ça pourra te faire très très mal...
De plus, un administrateur d'une de tes applis peut très bien vouloir attaquer les autres applis, il lui suffit d'une faille locale de Xen pour qu'il ait accès aux autres applis comme il veut, sans besoin de droits sur ces autres applis. Super.
Il y a des points négatifs mais il y en a aussi des positifs.
On a jamais dit le contraire. On a juste dit que la sécurité ne fait pas partie des points positifs, et est même un point négatif.
Faut juste le savoir quand tu utilises Xen. Après, tout dépend de ton niveau de sécurité demandé. Si il est faible, OK. Si il est haut, tu as fais une connerie dans ton choix de solution technique, surtout si tu n'as pas indiqué au décideur qu'il y a un risque potentiel d'attaque.
[^] # Re: Xen2
Posté par Zenitram (site web personnel) . En réponse à la dépêche Sortie d'OpenBSD 4.2. Évalué à 5.
Drôle de postulat.
Xen est un logiciel, fait par des humains qui ont pour habitude de faire des bugs dans les logiciels. Pourquoi Xen dérogerait-il à la règle?
Tu nous parles de la couche réseau, on parle depuis le début du code exécutable que tu rajoutes en plus à ta machine, code qui peut être buggé. On s'en fout de la couche réseau, le risque est identique quelque soit la solution.
Tu ajoutes une voie supplémentaire possible pour un attaquant, et tu crois qu'il ne va pas essayer de l'utiliser? Ouvre les yeux, regarde ce que tu fais : tu rajoutes des possibilités d'attaque.
Le pire est que tu peux avoir X applis robustes aux attaques, il en faut une, et une seule, pour que tes applis se fasse trouées dans le cas où une petites faille locale sur Xen arrive.
Donc il faut que tu puisses garantir que aucune de tes X applis n'a de trou de sécurité, ça démultiplie les risques de façon importante.
Tu es prêt à prendre le risque? OK, mais informe quand même tes supérieurs, sinon ça pourra te faire très très mal...
De plus, un administrateur d'une de tes applis peut très bien vouloir attaquer les autres applis, il lui suffit d'une faille locale de Xen pour qu'il ait accès aux autres applis comme il veut, sans besoin de droits sur ces autres applis. Super.
On a jamais dit le contraire. On a juste dit que la sécurité ne fait pas partie des points positifs, et est même un point négatif.
Faut juste le savoir quand tu utilises Xen. Après, tout dépend de ton niveau de sécurité demandé. Si il est faible, OK. Si il est haut, tu as fais une connerie dans ton choix de solution technique, surtout si tu n'as pas indiqué au décideur qu'il y a un risque potentiel d'attaque.