En ce moment, le principe de moindre privilège pour sécuriser les applications UNIX, c'est un peu mon dada. J'en ai parlé dans une dépêche sur Capsicum, qui est un modèle de sécurité très riche et très intéressant mais pas encore porté sous Linux (il est maintenant disponible dans FreeBSD par contre), une dépêche sur seccomp-filter, une autre technologie pour Linux beaucoup plus bas niveau mais (secrètement) reliée, et indirectement dans le troll sur le modèle de sécurité de l'apple store.
Je suis tombé aujourd'hui sur un billet très intéressant sur le blog de cr0, un ingénieur en sécurité chez Google (français, du reste), qui fait des liens entre tout ça :
Introduction Chrome's next-generation Linux sandbox
Où est le lien ? Les gens de Chrome font du sandboxing de leur browser depuis longtemps, en utilisant sur chaque système la solution qui leur semble la plus adaptée. Un ingénieur Google, Ben Laurie, s'est impliqué dans la recherche sur Capsicum en la faisant évoluer pour répondre à leurs besoins. C'est aussi un ingénieur Google, Will Drewry, qui a fait le travail sur seccomp-filter dans le but à moyen terme de s'en servir encore pour le sandboxing de Chrome. D'ailleurs un des soutiens du projet pendant les moments difficiles de débat dans la communauté kernel était Kees Cook, un spécialiste de la sécurité chez Ubuntu¹ qui a depuis été débauché par Google. Enfin, Will Drewry (et je pense certains des autres ingénieurs impliqués) travaillent maintenant sur ChromeOS, un système misant sur des applications tierces et cherchant donc des politiques de sécurité plutôt simples, un peu comme ce que met en place Apple.
¹: ça explique la référence à Ubuntu dans l'article pour les gens qui auront tiqué : "to make sure that you have kernel support for seccomp BPF, use Linux 3.5 or Ubuntu 12.04"; il ne s'agit pas de publicité gratuite pour la distribution, mais du fait bien concret qu'Ubuntu, par l'intermédiaire de Kees Cook, a intégré les patches seccomp-filter de Drewry avant qu'ils soient définitivement appliqués upstream, donc cette version de Ubuntu utilise un noyau "plus ancien" que 3.5 mais qui a déjà les patches.
Voilà, bonne lecture.
# Le dernier lien ne marche pas
Posté par needs . Évalué à 4.
Il devrait plutôt pointer vers http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html
[^] # Re: Le dernier lien ne marche pas
Posté par BAud (site web personnel) . Évalué à 3.
Il manquait le http devant, corrigé.
# Sandboxing et moindre privilège
Posté par muchos (site web personnel) . Évalué à 2.
Je ne comprends pas bien le lien entre le sandboxing et le principe de moindre privilège ici.
De ce que j'en sais, le sandboxing consiste juste à réaliser une opération dans un espace de test.
Debug the Web together.
[^] # Re: Sandboxing et moindre privilège
Posté par flan (site web personnel) . Évalué à 6.
Non, tu dois confondre avec autre chose, ou alors c'est l'expression bac-à-sable qui est trompeuse.
Si on met une application dans un bac-à-sable, ce n'est pas pour jeter ce qu'elle fait (faire des tests, donc), mais simplement pour qu'elle fasse ce qu'elle veut (y compris du travail utile, genre naviguer sur internet, écrire un texte, …) à l'intérieur de son bac-à-sable.
Si elle veut prendre un seau ou une nouvelle pelle, elle doit demander aux parents et ce sont eux qui acceptent et qui amènent les objets (comprendre : elle passe par des API système pour accéder aux autres ressources systèmes comme le système de fichiers).
# Capsicum
Posté par Maclag . Évalué à 10.
Je proteste contre cette technologie disponible uniquement sous Unix purs!
Dites à Lenart que… euh, non, rien…
-------------> [ ]
[^] # Re: Capsicum
Posté par Misc (site web personnel) . Évalué à 2.
Attends, tu aurais pu relancer le troll systemd avec juste ça :
http://lwn.net/Articles/507067/
Sinon, c'est quoi la différence par rapport à apparmor, ou selinux ? Autant je voit le point de détail technique qui distingue apparmor de selinux ( path based vs attribut based ), autant je vois pas encore la différence fondamental entre capsicum et les 2 autres, car ça semble globalement faire pareil ( ie dire "tu as droit à ça ou pas à ça avec des objets de tel groupe" ).
[^] # Re: Capsicum
Posté par gasche . Évalué à 3.
Avec capsicum la gestion des droits est totalement dynamique : ce n'est pas un choix préalable de "labels" qui détermine les autorisation de sécurité, ce sont les données que tu as (par exemple les descripteurs de fichiers ouverts) qui contiennent des restrictions sur l'usage que tu peux en faire, mais que tu peux transférer avec leurs droits à qui tu veux, sous forme de données. C'est un modèle plus flexible mais aussi moins structuré que ce qu'il y a dans les LSM.
Si ça t'intéresse il y a plus d'explications (liens pour approfondir, etc.) dans la dépêche Capsicum.
[^] # Re: Capsicum
Posté par Misc (site web personnel) . Évalué à 2.
En fait, soit je comprends pas ce que tu dis, soit j'ai une vision trop globale de selinux ( à mon avis, je pense que je comprends pas )
Si tu prends l'integration de selinux dans postgresql, on voit qu'on peut compartimenter au sein d'un programme ( en l'occurence, postgresql ) l'accés à des données internes ( en l'occurence, les bases ). Sauf erreur de ma part, ça se fait pas au niveau du filesystem, mais bien en interne :
http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture
Du coup, si je pige bien, ce qui fait la spécificité de capsicum ( qui va aussi séparer les objets manipulé ), c'est le fait que la source primaire de la politique appliqué sur les objets soit le programme lui même ( via son code ), et pas une base de référence externe ( en l'occurence pour selinux, la politique compilé dans le kernel ).
Du coup, ça me fait me poser plus de questions, dans le sens ou séparer ton process en composant ( ie ce que le papier appelle "logical applications" ) reviens plus ou moins à refaire le travail de l'os ( qui sépare tout sous forme de process ), mais sans avoir les couts de communications ? Et dans ce cas, si tu part du principe que les différents composants, c'est comme les process, j'ai le sentiment qu'on a pas un truc si différent de l'existant, et que ça évite juste de refaire les outils ?
[^] # Re: Capsicum
Posté par gasche . Évalué à 7.
Effectivement on ne s'est pas bien compris. Ce que je veux dire c'est que dans la tradition des systèmes à capacités, les données vont avec leur droit d'accès. Il n'y a plus de donnée "plate" sur laquelle tu fais des actions, tirées d'un ensemble global d'actions possible, en y étant autorisé ou pas par une politique de sécurité, chaque donnée vient avec l'ensemble des opérations qu'elle permet et c'est ce que tu utilises pour agir dessus. Par exemple les "file descriptors" utilisés en mode Capsicum contiennent des masques qui indiquent les droits que la possession du fd donne sur le fichier (ou plus généralement la ressource) correspondant. Donne ce fd à quelqu'un, et tu lui transfères du même coup ces droits. Et tu les as parce qu'à ton démarrage le système te les as fournis.
(Ça c'est dans un mode "tout capacité; capsicum est un système hybride unix/capacités où un processus lancée depuis le shell classique va avoir tous les droits de l'utilisateur, et donc la possibilité de "forger" ces file-descriptor avec les droits un peu qu'elle veut. Ensuite elle demande explicitement à passer en "mode capabilités" et il devient impossible de forger de nouveaux fd, on peut seulement en utiliser des existants ou en obtenir en communiquant avec un autre process)
Oui, c'est une différence plus concrète et moins philosophique. Ça fait qu'à mon avis les deux sont complémentaires : au développeur de réduire au maximum les droits demandés par son application en utilisant Capsicum ou autre, et l'admin de la machine peut par dessus rajouter des politiques SELinux/AppArmor qui correspondent à des contraintes supplémentaires locales (au risque de rendre inopérantes certaines fonctionnalités de l'appli). Un aspect important de l'approche "la sécurité est dans le code" est qu'en pratique pour ne pas utiliser trop de droits il faut un bon design, et le design il est décidé par le programmeur, donc il vaut mieux qu'il soit impliqué dans le début dans les questions de sécurité plutôt que mettre ça en jeu "après coup" avec un outil qui fonctionne "à l'extérieur".
Il y a une légère incompréhension ici: les autres de l'article proposent de changer les applications en les découpant en plein de petits processus pour faciliter le partage des privilèges (par exemple au lieu de faire tourner dans le processus maître le parsing des données utilisateur, on se méfie de cette tâche propices aux buffer overflow et on le fait tourner dans un sous-process forké depuis le maître, à qui on passe juste les file-descriptor des données concernées et aucun autre droit). Ils désignent par "logical application" le groupe de processus qui coopèrent pour faire ce que veut l'utilisateur, correspondant au process monolithique que tu avais avant.
Un exemple de découpage intéressant que j'utilise souvent : aujourd'hui quand tu veux ouvrir un fichier dans ton éditeur de texte, le code appelle la fonction "OpenFile" de l'API que tu utilises (Gtk ou Qt par exemple), qui va te proposer de naviguer dans ton filesystem. Ça veut dire que pour proposer cette fonctionnalité le programme doit avoir le droit de lecture sur tout le filesystem. Si à la place tu appelles un processus privilégié auxiliaire qui prend tes métadonnées en entrée (le type de fichier que tu veux, les droits que tu demandes dessus, tout ça), interagis avec l'utilisateur, et te rends le file_descriptor qui va bien ensuite, le programme lui-même n'a plus besoin de droit de lecture/exploration sur le filesystem, et c'est une grosse catégorie d'exploitations en moins à considérer en cas de faille d'injection de code. Mais pour pouvoir réduire ces privilèges il est crucial d'avoir pensé au découpage de l'application en plusieurs processus selon les bordures des droits nécessaires au fonctionnement des différentes parties.
Évidemment ça conduit à une augmentation des coûts de communication, mais personnellement j'abandonnerais avec plaisir un petit peu de perfs pour beaucoup plus de sécurité. C'est un peu la même chose que le débat {micro,macro}kernel, mais dans un domaine où les découpages restent plus gros et les performances souvent moins contraintes par la communication.
[^] # Re: Capsicum
Posté par reno . Évalué à 2.
Ce qui est très intéressant dans l'article c'est qu'il dit que le filtrage des appel systeme est complémentaire au capabilities.
Très intéressant mais un peu dommage: Linux a l'un et FreeBSD a l'autre et vice versa mais ils n'ont pas les deux!
# Misc
Posté par Spack . Évalué à 4.
A noter que le Misc #62 contient un très bon article détaillant le fonctionement de la sandbox de Chrome. On y apprend que ces malades s'amusent à décompiler le programme en live afin de détecter les appels systèmes pour gérer les droits d'accès.
[^] # Re: Misc
Posté par reno . Évalué à 2.
Le gros intérêt de seccomp-filter, c'est de pouvoir faire du filtrage d'appel système sans avoir a intégrer un décompilateur(!!).
# Android
Posté par claudex . Évalué à 2.
Pourquoi comparer le système de sécurité de Chrome OS à celui d'Apple et pas plutôt à celui d'Android ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Android
Posté par gasche . Évalué à 2.
Il y a eu une discussion sur LinuxFR suite à une dépêche sur la sécurité des applications tierces sous iOS, et cet article parle de ChromeOS, donc je compare les deux. Si tu veux que des gens parlent de la sécurité des applications sous Android, crée un journal ou une dépêche avec des liens qui en disent des choses intéressantes, ça lancera certainement une discussion aussi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.