Au point de vue sécurité, cela permet aux frameworks de sécurité
(SELinux, Apparmor...) d'éviter de faire confiance à l'userspace.
je suis modérement pas d'accord. D'une part, dans l'état des choses, le démon dbus fait l'arbitrage de qui a le droit de faire quoi via selinux et apparmor. Pour cela, il profite du fait qu'il a une vision globale sur les messages.
Bien sur, il est en userspace, mais il tourne dans un domaine de sécurité séparé du process userspace auquel on ne fait pas confiance, donc la distinction est plus complexe que kernel space vs userspace.
Et c'est ce point qui pose souci au dev de Canonical, car ils ont besoin de plus de précision que juste laisser passer ou non le message.
Actuellement, pour reprendre une analogie, le filtrage par selinux est de l'ordre d'un filtrage de niveau ip/tcp sur une couche réseau classique. Ce que Canonical a besoin pour confiner les applications, c'est plus un truc du style filtrage protocolaire. Ce qui se fait sans souci en userspace, et qui va avoir une énorme résistance au niveau du kernel. Et si le positionnement d'un tel filtre est évidement au lieu de passage dans le kernel, ça va pas aller.
Une solution serait de faire comme le défunt nufw, ie faire passer le message en userspace pour filtrage avant de retourner au kernel, mais ça devient inefficace. Une autre solution pourrait être une dérivation ( ie, le message va au destinataire et à un démon de filtrage, et le destinataire attends que le demon de filtrage dise "oui" ), mais la, on rajoute des délais un peu inutile et une architecture un peu plus complexe et fragile.
Donc je comprends que le passage vers le kernel dérange des gens, même si je pense qu'avec le temps, un moyen de filtrer efficacement soit ajouté dans le kernel.
[^] # Re: kdbus
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 4.
je suis modérement pas d'accord. D'une part, dans l'état des choses, le démon dbus fait l'arbitrage de qui a le droit de faire quoi via selinux et apparmor. Pour cela, il profite du fait qu'il a une vision globale sur les messages.
Bien sur, il est en userspace, mais il tourne dans un domaine de sécurité séparé du process userspace auquel on ne fait pas confiance, donc la distinction est plus complexe que kernel space vs userspace.
Et c'est ce point qui pose souci au dev de Canonical, car ils ont besoin de plus de précision que juste laisser passer ou non le message.
Actuellement, pour reprendre une analogie, le filtrage par selinux est de l'ordre d'un filtrage de niveau ip/tcp sur une couche réseau classique. Ce que Canonical a besoin pour confiner les applications, c'est plus un truc du style filtrage protocolaire. Ce qui se fait sans souci en userspace, et qui va avoir une énorme résistance au niveau du kernel. Et si le positionnement d'un tel filtre est évidement au lieu de passage dans le kernel, ça va pas aller.
Une solution serait de faire comme le défunt nufw, ie faire passer le message en userspace pour filtrage avant de retourner au kernel, mais ça devient inefficace. Une autre solution pourrait être une dérivation ( ie, le message va au destinataire et à un démon de filtrage, et le destinataire attends que le demon de filtrage dise "oui" ), mais la, on rajoute des délais un peu inutile et une architecture un peu plus complexe et fragile.
Donc je comprends que le passage vers le kernel dérange des gens, même si je pense qu'avec le temps, un moyen de filtrer efficacement soit ajouté dans le kernel.