Je pense pas que apparmor réponde à la problématique "je file tout un tas de lib en bundle".
Nitchevo parle d'un gros .deb, je dit qu'il suffirait de directement filer une appliance et basta. ( bien sur, c'était ironique mais visiblement, le sarcasme doit être explicite car distribuer 1 g de disque virtuel ne me semble pas viable personnellement )
Quand à dire que apparmor est éprouvé, je vais me permettre d’émettre des doutes.
Sur Ubuntu Precise, je compte 96 profiles dans apparmor-profiles, dont 29 pour les sous composants de postfix, plus divers doulons et triplets ( firefox compte pour 3, etc ), ce qui fait grosso modo 60 profiles. Ce qui fait en moyenne 12 profiles par an sur 5 ans, soit 1 profile par mois. Pour une technologie qui est proposé comme étant "plus simple que selinux", je trouve ce nombre curieusement bas. ( en fait si bas que j'ai chercher un autre paquet sans succès ).
À titre de comparaison, il y a 4089 types différents sur un F19, 1247 sur une wheezy. Si on prends que chaque programme va avoir en moyenne 4/5 types ( 1 pour le process, 2/3 pour les fichiers, parfois plus ), ça fait quand même de 2 à 8 fois plus de couverture.
Et tu pourrais te dire qu'avec 1 profile par mois, il y a le temps de peaufiner, mais visiblement pas vraiment ( cf ce lien que je ressort à chaque fois : http://blog.azimuthsecurity.com/2012/09/poking-holes-in-apparmor-profiles.html ). Je sais que faire une policy pour ce genre de choses requiert beaucoup de temps, de test, que les programmes sont assez compliqués, qu'il faut jongler entre "activer et bloquer par défaut puis voir les gens raler", ou "ne mettre ça qu'en opt-in puis ne pas avoir assez de retour". Et que les softs bougent sans arrêt pour le bonheur des petits et grands.
De plus, si AppArmor était suffisant, je pense qu'il n'y aurais pas besoin de coder tout un tas de choses qui manque, venant du document que tu donnes, je cite :
D-Bus will gain AppArmor mediation capabilities
Mir will be implemented with security hooks at appropriate places that AppArmor can plugin to.
If fine-grained access to GNOME Keyring is a requirement, GNOME Keyring will gain AppArmor integration
AppArmor will gain support for using a "PID" variable in profile rules
Ubuntu Online Accounts will gain AppArmor integration
Once a file is authorized, it could be dynamically loaded into the AppArmor profile by the daemon. This functionality doesn't currently exist in AppArmor
ça fait beaucoup de choses à coder ( mais le travail a déjà bien commencé pour dbus ).
Et comme j'assume totalement mon fanboyisme sur SElinux :
le 1, c'est déjà codé pour SElinux ( cf page de man de dbus-daemon ), mais que je sache peu exploité.
le 2, c'est un truc sur lequel la NSA bosse depuis 2/3 ans ( http://selinuxproject.org/page/Experimenting_With_X-Windows ). Ou d'autres gens que la NSA en fait ( http://lwn.net/Articles/517375/ ).
le 4, c'est fait nativement via SElinux vu que chaque entrée dans /proc a un label correspondant au processus. Je viens de vérifier sur l'instance publique d'openshift, j'ai pas accès au /proc des autres grâce à ça.
Je comprends parfaitement que Canonical ayant plus de compétences internes sur AppArmor préfère utiliser ça comme base, surtout si il y a pas mal de code à écrire pour mir, mais dire 4 fois dans la page que "apparmor est une technologie mature" ne rends pas la chose vraie pour autant.
Le credo d'AppArmor a toujours été "on utilise un système path based car c'est plus simple que les labels de SELinux" et c'est vrai, en retirant une couche d'indirection, tu simplifie grandement la compréhension. Mais les labels ont l'avantage de justement permettre ensuite de se mettre sur tout ce qui bouge, comme les processus, les bases de données, les objets dans xorg, les paquets réseau, etc.
Et la, avec tout ce que Canonical doit rajouter, la partie "path based et simplicité" risque d'être un peu moins vrai, et un peu moins élégante. Et si tu commences à greffer des nouveaux morceaux, ton code va plus être aussi mature et éprouvé qu'on pourrait croire.
[^] # Re: gros deb?
Posté par Misc (site web personnel) . En réponse au journal Un nouveau format de paquets pour Ubuntu. Évalué à 6.
Je pense pas que apparmor réponde à la problématique "je file tout un tas de lib en bundle".
Nitchevo parle d'un gros .deb, je dit qu'il suffirait de directement filer une appliance et basta. ( bien sur, c'était ironique mais visiblement, le sarcasme doit être explicite car distribuer 1 g de disque virtuel ne me semble pas viable personnellement )
Quand à dire que apparmor est éprouvé, je vais me permettre d’émettre des doutes.
Sur Ubuntu Precise, je compte 96 profiles dans apparmor-profiles, dont 29 pour les sous composants de postfix, plus divers doulons et triplets ( firefox compte pour 3, etc ), ce qui fait grosso modo 60 profiles. Ce qui fait en moyenne 12 profiles par an sur 5 ans, soit 1 profile par mois. Pour une technologie qui est proposé comme étant "plus simple que selinux", je trouve ce nombre curieusement bas. ( en fait si bas que j'ai chercher un autre paquet sans succès ).
À titre de comparaison, il y a 4089 types différents sur un F19, 1247 sur une wheezy. Si on prends que chaque programme va avoir en moyenne 4/5 types ( 1 pour le process, 2/3 pour les fichiers, parfois plus ), ça fait quand même de 2 à 8 fois plus de couverture.
Et tu pourrais te dire qu'avec 1 profile par mois, il y a le temps de peaufiner, mais visiblement pas vraiment ( cf ce lien que je ressort à chaque fois : http://blog.azimuthsecurity.com/2012/09/poking-holes-in-apparmor-profiles.html ). Je sais que faire une policy pour ce genre de choses requiert beaucoup de temps, de test, que les programmes sont assez compliqués, qu'il faut jongler entre "activer et bloquer par défaut puis voir les gens raler", ou "ne mettre ça qu'en opt-in puis ne pas avoir assez de retour". Et que les softs bougent sans arrêt pour le bonheur des petits et grands.
De plus, si AppArmor était suffisant, je pense qu'il n'y aurais pas besoin de coder tout un tas de choses qui manque, venant du document que tu donnes, je cite :
ça fait beaucoup de choses à coder ( mais le travail a déjà bien commencé pour dbus ).
Et comme j'assume totalement mon fanboyisme sur SElinux :
le 1, c'est déjà codé pour SElinux ( cf page de man de dbus-daemon ), mais que je sache peu exploité.
le 2, c'est un truc sur lequel la NSA bosse depuis 2/3 ans ( http://selinuxproject.org/page/Experimenting_With_X-Windows ). Ou d'autres gens que la NSA en fait ( http://lwn.net/Articles/517375/ ).
le 4, c'est fait nativement via SElinux vu que chaque entrée dans /proc a un label correspondant au processus. Je viens de vérifier sur l'instance publique d'openshift, j'ai pas accès au /proc des autres grâce à ça.
Je comprends parfaitement que Canonical ayant plus de compétences internes sur AppArmor préfère utiliser ça comme base, surtout si il y a pas mal de code à écrire pour mir, mais dire 4 fois dans la page que "apparmor est une technologie mature" ne rends pas la chose vraie pour autant.
Le credo d'AppArmor a toujours été "on utilise un système path based car c'est plus simple que les labels de SELinux" et c'est vrai, en retirant une couche d'indirection, tu simplifie grandement la compréhension. Mais les labels ont l'avantage de justement permettre ensuite de se mettre sur tout ce qui bouge, comme les processus, les bases de données, les objets dans xorg, les paquets réseau, etc.
Et la, avec tout ce que Canonical doit rajouter, la partie "path based et simplicité" risque d'être un peu moins vrai, et un peu moins élégante. Et si tu commences à greffer des nouveaux morceaux, ton code va plus être aussi mature et éprouvé qu'on pourrait croire.