Userland ou kernel (OT)
Le
uwo-8e
Hello,
Je me permets cette question ici, vu votre niveau general ;-)
Dans un message plus bas, on parle de VPN en mode "kernel" ou en mode
"user"
D'une facon generale (si on peut generaliser), quel(s) avantages et
soucis cela peut procurer d'avoir une application userland a la place
de kernel-land?
Au niveau de la securite?
Merci
Max
Je me permets cette question ici, vu votre niveau general ;-)
Dans un message plus bas, on parle de VPN en mode "kernel" ou en mode
"user"
D'une facon generale (si on peut generaliser), quel(s) avantages et
soucis cela peut procurer d'avoir une application userland a la place
de kernel-land?
Au niveau de la securite?
Merci
Max
Pour userland: plus facile à developper, séparation des privileges donc
plus de sécurité.
Pour kernel: potentiellement gains en performances car on evite des
changements de contexte.
--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Maximus
Je reviens au thème des VPNs pour discuter à partir de ta question,
étant entendu qu' E. Dreyfuss y a déjà répondu de façon précise.
Dans ce domaine le choix n'est pas seulement une question de performances.
Et il ne se résoud pas totalement dans la problématique opposant
« d'une facon generale » kerneland et userland ; je regrette que la
formulation de mon précédent message ai pu favoriser ce léger contresens.
En fait il fallait entendre: « le choix de certaines technologies
impliquant de fait une forte solicitation et de larges spécifités noyau »
(kerneland), et « le choix d'autres technologies moins dépendantes des
fonctionalités disponibles ou non dans le noyau ». Sachant que les
premières nécessitent généralement un complément userland pour être vraiment
fonctionnelles (comme racoon, isakmpd, ipsecadm etc.) et que les secondes
peuvent recquerir certaines fonctionnalités kernel relativement spécifiques
(au hasard, le driver tun(4)).
Je profite de l'occasion pour préciser mon propos (et peut être
anticiper une de tes questions ?).
Ce qui me semble plus déterminant dans le choix d'une technologie VPN
(userland ou kerneland) c'est le protocole qu'elle implémente (la
qualité de l'implémentation est certainement très importante aussi, mais
il n'est jamais aisé d'en juger).
Or il se trouve qu'il n'existe pas (à ma connaissance) d'implémentation
purement userland d'IPsec sous *BSD, et que ce protocole est néanmoins
assez important dans le domaine des VPN parcequ'il est l'un des rares
ouvertement normalisé et implémenté par un très grand nombre d'acteurs
(les 3 BSD libres, GNU/linux, windows2k/xp, certains IOS Cisco, Checkpoint
VPN-1, les HP-UX et Solaris récents ...).
Pour donner mon avis à deux centimes (et très discutable), le choix oppose
essentiellement un protocole - théoriquement - très interopérable (mais
complexe à deployer) à une foultitude de protocoles ou logiciels (pptp,
htun, amrita, cipe, slan, nets, openvpn, ...) peut ou pas interopérables mais
souvent très simple à mettre en place (surtout si l'on doit traverser une
couche de NAT) ; que celà fonctionne ou non « dans » le kernel est assez
secondaire en somme.
Comme l'a justement fait remarquer Thomas Pornin, la complexité dans ce cas
n'est pas liée au fait de devoir parfois modifier légèrement le noyau (sauf
quand on veut avoir FreeS/Wan avec X.509 et simple DES avec un noyau linux
2.4.* ;-). Elle serait plutôt conséquence de l'architecture des protocoles
respectifs et de leur implémentation (notament l'implémentation des
interfaces de paramétrage).
Je continue de répondre sur le cas précis des VPNs (donc pas exactement
à ta question sur une éventuelle dimension générale).
On se trouve dans une situation opposant une technologie (IPsec) conçue
par de nombreux experts en sécurité et validée sur le long terme par un
grand nombre d'acteurs face à une série de technologies souvent moins
auditées, et pouvant par conséquent réveler sur le moyen terme d'importantes
erreurs de conceptions impactant sur la sécurité (cf. par exemple le cas
d'école Vtun).
Un autre avantage d'IPsec ayant trait à la sécurité est qu'il est fournis
avec l'OS (du moins pour les *BSDs libres, qu'il soit activé par défaut ou
non); il est par conséquent maintenu avec l'OS, et les mises à jour s'en
trouvent facilités.
Bref, qu'IPsec soit généralement implementé au niveau du noyau de l'OS
alors que d'autres protocoles fonctionnent en userland (ou pas) ne devrait
pas, en soi, avoir de conséquences immédiate sur la sécurité.
Je crois que cette remarque est à peu près généralisable : le niveau
d'execution d'un logiciel (kernel ou pas) n'est pas en soi un critère
décisif concernant la sécurité.
--
Benjamin
J'ai une petite question à propos du vpn
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la
hauteur de freeswan????
14:35, "voodoo child"
Les BSD utilisent l'implémentation KAME, de même que Linux
2.6. Freeswan n'est plus développé.
--
SUBSTITUTE TEACHERS ARE NOT SCABS
SUBSTITUTE TEACHERS ARE NOT SCABS
SUBSTITUTE TEACHERS ARE NOT SCABS
-+- Bart Simpson on chalkboard in episode BABF09
'Lut,
voodoo> sur linux la rèf c'est freeswan. D'une manière générale, c'est
voodoo> la référence.
On a les références que l'on peut, mais celle ci était tout de même
particulièrement pourrie, le code de Kame a fini par être intégré dans
la série 2.6.
voodoo> Mais quel est l'équivalent dans le monde bsd.
Les implémentations ipsec de chacun des bsd (toutes dérivées de Kame,
même si Free et Open ont chacun ajouté le support de la crypto via
hardware, iirc, Net doit avoir en projet d'intégrer le support hardware
des deux autres)
voodoo> Est-ce que vtun arrive à la hauteur de freeswan????
Euh, ça ne fait pas la même chose à la base, cela reviendrait à comparer
des choux et des carottes.
IPsec est normalisé et d'usage général, là ou vtun est un outil ne
sachant interopérer qu'avec lui même et dont la fonction est le
tunnelling.
Eric Masson
--
Et manque de bol, ça accélère énormément cette nouvelle version (à
croire que l'ancienne était codée en 68k et utilisait ApplScript).
-+- SC in Guide du Macounet Pervers : Jobs, stakhanoviste ? Nooon ! -+-
voodoo child
On peut difficilement dire que FreeS/Wan soit « la référence générale ».
D'une part parcequ'il ne fonctionne qu'avec linux (et seulement pour les
noyaux < 2.6 pour la partie klips), d'autre part parceque l'implem est
particulièrement moche (pas de support X.509 sans repatcher sur le patch,
pas de simple DES, pas d'IPv6, empilements d'affreux shells scripts ...) et
pour finir, parceque même les devs du noyau linux l'ont désavoué, lui
préférant l'implémentation d'USAGI (le jumeau de kame) pour la nouvelle
génération de noyau ; à vrai dire, ils n'ont jamais accepté d'intégrer
FreeS/Wan dans les sources du noyau standard, non sans raisons, c'est
dire sa qualité de « référence ».
Bref, comme d'autres l'ont dit, le stack USAGI/KAME (et les serveurs de
clefs isakmpd et racoon) mériterai le qualificatif de « références »
dans le monde des OS libres bien avant FreeS/Wan. Reste à attendre que
les linuxiens cessent de polluer les réseaux avec ce machin (d'ici 25
ans, quand debian aura intégré le noyau 2.6 en std ? ;).
J'ai bon espoir tout de même : http://www.freeswan.org/ending_letter.html
D'un certaine manière, oui. Le design de vtun est unaniment reconnu comme une
abération en matière de sécurité (p. ex. http://off.net/~jme/vtun_secu.html).
Il offre en outre tout les charmes d'un protocole maison et non-interropérable.
Et il reste néanmoins très populaire dans le monde linux. À la hauteur de fs.
L'équivalent (si l'on peut dire) dans le monde BSD est Kame, le stack
IPv6 & IPsec BSD. Il est intégré out of the box sur les 3 BSD (et activé
par défault seulement sous open). Coté serveur de clefs, en plus de
l'implem de kame (racoon) on peut utiliser isakmpd qui fait des merveilles
(et photurisd aussi).
Tu as raison à propos de vtun, il est interopérable uniquement avec lui
même. Mais d'une manière
génréle vtun permet de faire du vpn mais s'il n'utilise pas ipsec