tag:linuxfr.org,2005:/tags/capabilities/publicLinuxFr.org : les contenus étiquetés avec « capabilities »2022-11-14T16:27:54+01:00/favicon.pngtag:linuxfr.org,2005:Bookmark/53872022-11-13T09:10:53+01:002022-11-13T09:10:53+01:00Linux capabilities<a href="https://github.com/SamerW/RootAsRole">https://github.com/SamerW/RootAsRole</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/129281/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/samerw/liens/linux-capabilities#comments">ouvrir dans le navigateur</a>
</p>
samerwhttps://linuxfr.org/nodes/129281/comments.atomtag:linuxfr.org,2005:News/394952019-10-25T13:18:43+02:002022-03-06T21:36:44+01:00Version 2 du RootAsRole : se passer des commandes sudo et su sous GNU/LinuxLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Le module RAR (<em>Root As Role</em>) implémente une approche basée sur les rôles pour distribuer les privilèges aux utilisateurs. Il fournit une solution qui permet aux utilisateurs de contrôler la liste des privilèges qu’ils accordent aux programmes. Grâce à ce module, les administrateurs peuvent regrouper les privilèges Linux dans des rôles et les donner à leurs utilisateurs. Pour des raisons de sécurité, les utilisateurs n’obtiennent pas les rôles attribués par défaut, ils doivent les activer à l’aide de la commande <em>sr</em> (changer de rôle).</p>
<p><a href="https://github.com/SamerW/RootAsRole/blob/master/doc/assumerootrole.png"><img src="https://linuxfr.org/images/historique/images_perdues/version-2-du-rootasrole-se-passer-des-commandes-sudo-et-su-sous-gnu-linux-iyvoCdlgYZVW.png" alt="Copie d’écran de Root As Role"></a></p>
<p>Cependant, la première version du RAR ne fournissait pas à l’administrateur la possibilité de connaître l’ensemble des privilèges qui sont demandés par un programme. Cette deuxième version ajoute l’outil <em>capable</em> qui permet à l’administrateur de disposer de cette information. Nous pensons que cet outil va largement contribuer à l’adoption de RootAsRole.</p>
</div><ul><li>lien nᵒ 1 : <a title="https://github.com/SamerW/RootAsRole" hreflang="fr" href="https://linuxfr.org/redirect/105070">Page GitHub de Root As Role</a></li><li>lien nᵒ 2 : <a title="https://docs.google.com/forms/d/e/1FAIpQLSfwXISzDaIzlUe42pas2rGZi7SV5QvUXXcDM9_GknPa8AdpFg/viewform" hreflang="fr" href="https://linuxfr.org/redirect/105071">Formulaire de retour d’information (sur Google Forms)</a></li></ul><div><p>Nous vous avons proposé l’année dernière le module RootAsRole qui permet de se passer des commandes <em>su</em> et <em>sudo</em> sous GNU/Linux (voir le journal « <a href="//linuxfr.org/news/linux-capabilities-se-passer-des-commandes-su-et-sudo">Linux capabilities : se passer des commandes su et sudo</a> »). En effet, le problème majeur des commandes <em>sudo</em> et <em>su</em>, c’est que cette approche traditionnelle ne respecte pas le principe plus récent de moindre privilège : ces commandes ne permettent pas de contrôler les listes de privilèges (<em>Linux capabilities</em>) à donner aux programmes et/ou utilisateurs.</p>
<p>Le code (GPL v3) et des exemples plus complets sont disponibles sur la <a href="https://github.com/SamerW/RootAsRole">page GitHub</a> du projet.</p>
<p>N’hésitez pas à nous envoyer vos retours via le <a href="https://docs.google.com/forms/d/e/1FAIpQLSfwXISzDaIzlUe42pas2rGZi7SV5QvUXXcDM9_GknPa8AdpFg/viewform">formulaire</a> à disposition (formulaire hébergé sur Google Forms).</p>
</div><div><a href="https://linuxfr.org/news/version-2-du-rootasrole-se-passer-des-commandes-sudo-et-su-sous-gnu-linux.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/118376/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/version-2-du-rootasrole-se-passer-des-commandes-sudo-et-su-sous-gnu-linux#comments">ouvrir dans le navigateur</a>
</p>
samerwZeroHeureDavy DefaudXavier TeyssierBenoît SibaudgUIYsabeau 🧶 🧦https://linuxfr.org/nodes/118376/comments.atomtag:linuxfr.org,2005:News/387752018-09-06T09:44:52+02:002018-09-06T23:47:28+02:00Linux capabilities : se passer des commandes su et sudoLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Nous proposons un module qui permet de se passer des commandes <code>su</code> et <code>sudo</code>. L’avantage de notre module est qu’il permet de contrôler la liste des privilèges donnés aux programmes.</p>
<p>Traditionnellement, l’administration des systèmes GNU/Linux repose sur l’existence d’un seul utilisateur puissant (appelé super‐utilisateur) qui détient à lui seul la liste complète des privilèges du système. Cette vision a été critiquée car tous les programmes exécutés dans le contexte du super‐utilisateur obtiennent beaucoup plus de privilèges qu’ils n’en ont besoin. Par exemple, <code>tcpdump</code> demande uniquement le privilège <code>cap_net_raw</code> pour s’exécuter. Cependant, en l’exécutant dans le contexte de super‐utilisateur, <code>tcpdump</code> obtient la liste complète des privilèges du système. Ainsi, l’approche traditionnelle de l’administration GNU/Linux rompt le principe du moindre privilège, qui garantit qu’un processus doit juste avoir les privilèges nécessaires pour effectuer son travail. Un attaquant pourrait exploiter les vulnérabilités de <code>tcpdump</code> afin de compromettre la sécurité du système.</p>
<p>Il existe cependant une autre voie, non officielle, mais intégrée au noyau Linux depuis 1998…</p>
</div><ul><li>lien nᵒ 1 : <a title="https://github.com/SamerW/RootAsRole/" hreflang="fr" href="https://linuxfr.org/redirect/102632">RAR module</a></li></ul><div><p>Un brouillon POSIX (POSIX draft 1003.1e) avait été proposé afin de définir un modèle qui permet de donner aux processus uniquement les privilèges de super‐utilisateur dont ils ont besoin. La proposition définit pour chaque processus trois ensembles de <em>bitmaps</em> appelés <em>Inheritable</em> (i), <em>Permitted</em> (p) et <em>Effective</em> (e). Ce modèle n’a pas été adopté officiellement, mais il a été intégré au noyau Linux depuis 1998.</p>
<p>Cependant, pour différentes raisons, ce modèle n’a pas été largement utilisé : </p>
<ol>
<li>Premièrement, le modèle de capacité de Linux présente différents problèmes techniques en raison de l’utilisation d’attributs étendus pour stocker les privilèges dans les exécutables (problème 1). </li>
<li>Deuxièmement, les administrateurs de systèmes GNU/Linux ne disposent pas d’un outil leur permettant de distribuer les privilèges aux utilisateurs de manière fine (problème 2). La distribution fine de privilèges devrait donner aux administrateurs la possibilité de décider quels privilèges accorder aux utilisateurs, quels programmes (par exemple, <code>tcpdump</code>) peuvent utiliser ces privilèges et sur quelles ressources ces privilèges peuvent être appliqués (par exemple, interface réseau <em>eth0</em>). </li>
<li>Troisièmement, GNU/Linux ne fournit pas d’outil permettant aux utilisateurs de connaître le privilège demandé par une application (problème 3). </li>
<li>Quatrièmement, GNU/Linux est livré avec des commandes de base qui ne sont pas compatibles avec des privilèges, tels que la commande <code>passwd</code> (problème 4). </li>
</ol>
<p>En conséquence, la majorité des utilisateurs de GNU/Linux utilisent toujours les commandes <code>su</code> et <code>sudo</code> pour exécuter des applications privilégiées, car le modèle super‐utilisateur présente l’avantage d’être facile à utiliser.</p>
<p>Récemment, un nouvel ensemble de privilèges appelé <em>Ambient</em> a été intégré au noyau Linux afin de résoudre les problèmes techniques liés au stockage des privilèges dans les attributs étendus des exécutables. Cependant, le système GNU/Linux ne fournit pas de solutions pour gérer les problèmes deux et trois.</p>
<p>Le module RAR (<em>Root As Role</em>) implémente une approche basée sur les rôles pour distribuer les privilèges aux utilisateurs. Il fournit une solution au problème deux : notre module est livré avec un outil appelé <code>sr</code> (<em>switch role</em>) qui permet aux utilisateurs de contrôler la liste des privilèges qu’ils accordent aux programmes.</p>
<p>Ainsi, avec notre module, les utilisateurs de GNU/Linux peuvent cesser d’utiliser les commandes <code>sudo</code> et <code>su</code>, qui ne permettent pas de contrôler la liste des privilèges à donner aux programmes. </p>
<p>Il existe déjà des outils permettant de contrôler la liste des privilèges à attribuer aux programmes tels que <code>setcap</code> et le module <code>pam_cap</code>. Cependant, ces outils nécessitent l’utilisation d’attributs étendus pour stocker les privilèges. Or stocker des privilèges dans des attributs étendus pose de nombreux problèmes. Notre module permet d’attribuer les privilèges Linux sans avoir besoin de les stocker dans les attributs étendus des fichiers exécutables. </p>
<p>Grâce à ce module, les administrateurs peuvent regrouper les privilèges Linux dans des rôles et les donner à leurs utilisateurs. Pour des raisons de sécurité, les utilisateurs n’obtiennent pas les rôles attribués par défaut, ils doivent les activer à l’aide de la commande <code>sr</code> (changer de rôle). </p>
<p>Notre module est compatible avec <code>pam_cap.so</code>, les administrateurs peuvent donc continuer à utiliser <code>pam_cap.so</code> avec lui. </p>
<p>Concrètement, notre module permet de respecter le principe du moindre privilège en donnant aux utilisateurs la possibilité de contrôler la liste des privilèges qu’ils accordent à leurs programmes.</p>
<p>Le code (GPL v3) et des exemples plus complets sont disponibles sur la <a href="https://github.com/SamerW/RootAsRole/">page GitHub du projet</a>.</p>
</div><div><a href="https://linuxfr.org/news/linux-capabilities-se-passer-des-commandes-su-et-sudo.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/115209/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/linux-capabilities-se-passer-des-commandes-su-et-sudo#comments">ouvrir dans le navigateur</a>
</p>
wazanBenoît SibaudZeroHeurePierre Jarillonbubar🦥Davy Defaudhttps://linuxfr.org/nodes/115209/comments.atomtag:linuxfr.org,2005:Post/347152014-11-30T10:39:58+01:002014-11-30T10:48:36+01:00gestion des capabilities<p>Bonjour.<br>
Dans le cadre de mon projet jiguiviou, j'expérimente un client GVSP (un client de flux vidéo très haut débit) avec une socket dont le ring buffer est mappé en espace utilisateur. La gestion des interruptions du NIC et les multiples appels systèmes générés par recvmmsg consomment beaucoup de temps CPU, j'espère trouver dans cette méthode une solution élégante.<br>
Pour cela j'utilise une socket packet. Le processus doit avoir un UID effectif nul ou la capacité CAP_NET_RAW.<br>
J'ai donc isolé le peu de code avec cette fonctionnalité dans une bibliothèque séparée.<br>
Me voilà donc maintenant au niveau de la gestion des droits de cette bibliothèque.<br>
Pour le développement, je teste en tant que root, je ne me pose ainsi aucune question, l'implémentation du ring buffer m'étant déjà assez énergivore.</p>
<p>Le sujet étant posé, je sollicite votre expérience pour m'orienter vers une solution à ce problème<br>
1. pour le débogage (j'utilise CMAKE pour la gestion de projet et qtcreator comme IDE)<br>
2. le déploiement avec CMAKE</p>
<p>Merci</p>
<p>PS: je ne lis pas très bien l'anglais, ce qui n’arrange pas mes problèmes.</p><div><a href="https://linuxfr.org/forums/programmation-c/posts/gestion-des-capabilities.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/104110/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/programmation-c/posts/gestion-des-capabilities#comments">ouvrir dans le navigateur</a>
</p>
tmphttps://linuxfr.org/nodes/104110/comments.atomtag:linuxfr.org,2005:News/279952011-03-21T17:06:08+01:002021-07-11T18:47:52+02:00Capsicum, une séparation fine des privilèges pour UNIXLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<div><p>Le projet <em>Capsicum</em>, lancé l'année dernière, tente d’adapter le modèle de sécurité par capacités (« capabilities ») aux systèmes UNIX. En deux mots, il s’agit de permettre aux applications de faire tourner certaines parties de leur code dans des « <a href="http://fr.wikipedia.org/wiki/Sandbox_%28s%C3%A9curit%C3%A9_informatique%29"><em>sandboxes</em></a> » (bacs à sable) aux droits très restreints, gérés finement, avec la possibilité de recevoir ou de déléguer dynamiquement une partie de ces droits.</p>
<p>C’est une approche de la sécurité qui mise sur la flexibilité et l’intégration directe dans les applications (au contraire de politiques externes décidées par l’administrateur système, comme avec <a href="https://fr.wikipedia.org/wiki/SELinux" title="Définition Wikipédia">SELinux</a>) pour respecter le <em><a href="https://fr.wikipedia.org/wiki/Principle%20of%20Least%20Authority" title="Définition Wikipédia">Principle of Least Authority</a></em>, qui recommande qu’un bout de programme donné fonctionne avec seulement les droits dont il a besoin pour accomplir sa tâche. Ainsi, les conséquences d’une faille sont réduites et les vecteurs d’attaque diminuent énormément. Par exemple, je ne veux pas que le logiciel qui lit mes fichiers PDF ait le droit de lire le contenu de mon répertoire personnel et d’envoyer des e-mails.</p>
<p>Capsicum introduit de nouveaux appels et objets système, qui demandent une (relativement petite) modification du noyau, ainsi qu’une bibliothèque logicielle en espace utilisateur pour utiliser ces nouveaux appels système. FreeBSD a déjà fait les modifications nécessaires, et les chercheurs ont pu facilement convertir plusieurs applications au modèle Capsicum : <code>tcpdump</code>, <code>dhclient</code>, <code>gzip</code> et, avec l’aide d’un développeur Google, le navigateur Web <code>chromium</code>.</p>
<p>Capsicum peut ainsi renforcer considérablement la sécurité des applications UNIX classiques, sans demander de les recoder entièrement. Reste à voir si les développeurs du monde du Libre seront convaincus par ces approches compartimentées, et prêts à les prendre en compte lors de la conception de leurs logiciels.</p>
</div><ul><li>lien nᵒ 1 : <a title="http://fr.wikipedia.org/wiki/Capsicum" hreflang="fr" href="https://linuxfr.org/redirect/71351">Capsicum, un genre botanique qui contient poivrons et piments</a></li><li>lien nᵒ 2 : <a title="http://www.cl.cam.ac.uk/research/security/capsicum/" hreflang="en" href="https://linuxfr.org/redirect/71352">La page du projet Capsicum au laboratoire de sécurité de Cambridge (UK)</a></li><li>lien nᵒ 3 : <a title="http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf" hreflang="en" href="https://linuxfr.org/redirect/71353">les transparents de la présentation (PDF, 31 pages) données à la conférence USENIX en août dernier</a></li><li>lien nᵒ 4 : <a title="http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf" hreflang="en" href="https://linuxfr.org/redirect/71354">L'article 'Capsicum: practical capabilities for UNIX' (PDF, 17 pages), par Robert Watson et Jonatha</a></li><li>lien nᵒ 5 : <a title="http://www.cl.cam.ac.uk/research/security/capsicum/" hreflang="fr" href="https://linuxfr.org/redirect/71355">Le site du projet Capsicum</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<ul>
<li><a href="#toc-la-s%C3%A9curit%C3%A9-par-capacit%C3%A9s">La sécurité par capacités</a></li>
<li><a href="#toc-une-bonne-id%C3%A9e-longtemps-oubli%C3%A9e">Une bonne idée longtemps oubliée</a></li>
<li><a href="#toc-le-projet-capsicum">Le projet Capsicum</a></li>
<li><a href="#toc-et-%C3%A7a-marche">Et ça marche ?</a></li>
</ul>
</li>
</ul>
<h3 id="toc-la-sécurité-par-capacités">La sécurité par capacités</h3>
<p>La sécurité par capacités n’est pas une idée nouvelle : elle a été introduite en 1966 par Dennis et Van Horn, dans un article concernant les systèmes multi-utilisateur. Une capacité est une référence non-forgeable qui, simultanément, désigne un objet du système (fichier, périphérique…) et décrit une action autorisée sur cet objet (renommer le fichier, écrire sur le périphérique, etc.). La seule façon d’effectuer une action est de posséder et d’activer une capacité associée.</p>
<p>Dans un système UNIX classique (UNIX n’existait pas en 66, c’était la naissance de son ancêtre <a href="https://fr.wikipedia.org/wiki/MULTICS" title="Définition Wikipédia">MULTICS</a>), ce sont les objets du système qui « connaissent » les droits qui les concernent. Par exemple, les permissions d’un fichier indiquent quels utilisateurs peuvent y accéder et de quelle façon. Les capacités renversent la perspective : ce sont les <em>agents</em> du systèmes qui ont à leur disposition une liste d’actions autorisées.</p>
<p>Cela permet une gestion plus dynamique et plus fine des droits, car la notion d’« agent » peut être très fine : quand un programme lance un sous-programme, ou quand un utilisateur lance un programme, il peut choisir naturellement quelles capacités lui transmettre. Le <em>Principle Of Least Authority</em> est beaucoup mieux respecté que dans un système UNIX classique, où tous les processus lancés par le même utilisateur ont tous les droits de l’utilisateur : il y a une autorité « ambiante » qui peut être abusée.</p>
<p>Une capacité doit être non-forgeable pour qu’un agent ne puisse effectuer que les actions dont les droits lui ont été attribués. Ainsi, les utilisateurs n’ont pas accès au système de fichiers dans son ensemble, ils ne « voient » que les fichiers sur lesquels ils ont une capacité de lecture. Enfin, le fait de coupler la <em>désignation</em> d’un objet et l’<em>autorité</em> sur l’action qui l’accompagne, permet d'éviter les attaques de type « <a href="http://en.wikipedia.org/wiki/Confused_deputy_problem"><em>confused deputy</em></a> ».</p>
<p>Enfin, attention à ne pas confondre, les capacités du monde de la sécurité sont différentes des « <em>POSIX capabilities</em> », des systèmes de contrôle de droits beaucoup plus grossiers (cf. cet <a href="http://lwn.net/Articles/212962/">argumentaire</a>).</p>
<p>Aller plus loin :</p>
<ul>
<li>« <a href="http://www.eros-os.org/essays/capintro.html"><em>What Is A Capability, Anyway?</em></a> », une bonne introduction aux capacités. C’est un essai engagé, dans lequel le reste est décrit comme « médiocre » ;</li>
<li>l’article Wikipédia anglais <a href="http://en.wikipedia.org/wiki/Confused_deputy_problem"><em>Confused Deputy Problem</em></a> explique ce problème de sécurité et la façon dont les capacités contribuent à le résoudre ;</li>
<li>« <a href="http://old.nabble.com/On-the-Spread-of-the-Capability-Approach-td5608409.html"><em>On the Spread of the Capability Approach</em></a> », une courte reconstitution de l’histoire des capacités ;</li>
<li>« <a href="http://www.cap-lore.com/CapTheory/"><em>Capability Theory by Sound Bytes</em></a> », un site qui recense de nombreux documents sur les capacités ;</li>
<li>L’article originel <a href="http://www.princeton.edu/%7Erblee/ELE572Papers/Fall04Readings/ProgramSemantics_DennisvanHorn.pdf"><em>Programming Semantics for multiprogrammed computations</em></a> (PDF, 13 pages), Jack Dennis and Earl Van Horn, 1966 ;</li>
<li>« <a href="http://www.eros-os.org/papers/paradigm-final.pdf"><em>Paradigm Regained: Abstraction Mechanisms for Access Control</em></a> », par Mark Miller et Jonathan Shapiro, 2003. Une présentation récente et plus formelle du modèle « <em>object capability</em> » ;</li>
<li>« <a href="http://www.eros-os.org/papers/secnotsep.pdf"><em>The Structure of Authority: Why security is not a separable concern</em></a> », un article qui explique pourquoi on ne peut pas considérer la sécurité après-coup ou à part, et que le <em>Principle of Least Authority</em> doit être présent dès la phase de conception d’une application.</li>
</ul>
<h3 id="toc-une-bonne-idée-longtemps-oubliée">Une bonne idée longtemps oubliée</h3>
<p>Malgré des débuts prometteurs, l’idée des capacités a quasiment été oubliée dans les années 1980. Plusieurs causes ont contribué à cet échec : d’abord, le concept de « renversement de point de vue » par rapport aux <em><a href="https://fr.wikipedia.org/wiki/Access%20Control%20List" title="Définition Wikipédia">Access Control List</a></em> a paradoxalement répandu l’idée que les capacités n’apportaient en fait rien de nouveau, et que tout ce qui était fait pourrait aussi bien être fait, de façon symétrique, avec les listes d’accès de contrôle. Cette « méconception » ignore le fait que la gestion des droits au niveau de l’agent, et non de l’objet, permet une granularité beaucoup plus fine que les utilisateurs ou groupes utilisés dans les systèmes ACL classiques. Un modèle de droits doit être considéré de façon dynamique (modification et transmission des droits) et pas seulement statiquement, à un instant donné.</p>
<p>De plus, les premiers systèmes de capacités ne permettaient pas la révocation (le fait de retirer des droits qu'on a donné à un autre agent), et permettaient à chaque processus de diffuser ses propres droits sans restriction, ce qui met en péril les modèles de sécurité militaires où l’on veut garantir, par exemple, qu’une personne ayant accès à des documents « top secret » ne peut pas pour autant les faire lire à un simple moussaillon. On a depuis montré que les capacités permettaient en fait ces deux choses, mais le préjugé est resté.</p>
<p>Enfin et surtout, l’énorme succès d’UNIX, ayant une approche fondamentalement opposée à celle des capacités, a rapidement étouffé la recherche de systèmes alternatifs et incompatibles (cf. le pessimiste et grinçant <a href="http://herpolhode.com/rob/utah2000.pdf"><em>Systems Software Research is Irrelevant</em></a> (PDF, 23 transparents) de Rob Pike).</p>
<p>Cependant, un petit groupe d’irréductibles a continué à travailler sur les capacités. En particulier, les micro-noyaux (un autre franc succès du monde de l’informatique) ont souvent utilisé des capacités, car leur emploi est très naturel dans un contexte de passage de messages. En particulier les systèmes KeyKOS puis EROS ont montré qu’une conception entièrement basée sur les capacités était possible, sans perte de performances.</p>
<p>Mais les capacités peuvent être déployées à plus haut niveau que le noyau d’un système. Ainsi, <a href="http://research.google.com/pubs/author35958.html">Mark Miller</a> a développé le langage de programmation <a href="http://en.wikipedia.org/wiki/E_%28programming_language%29">E</a>, épousant entièrement le concept de capacité, qui permet d’écrire des programmes distribués et sécurisés.</p>
<p>Enfin, l’environnement de bureau <a href="http://en.wikipedia.org/wiki/CapDesk">Capdesk</a> a été écrit en E, et démontre qu’une interface utilisateur peut intrinsèquement favoriser la sécurité. Un exemple simple : sur un système classique, quand un utilisateur veut ouvrir un nouveau fichier dans son application préférée, celle-ci ouvre un « dialogue de choix de fichier » qui lui permet de naviguer dans son système et de choisir le fichier désiré que l’application ouvre ensuite. Mais pour faire cela, l’application doit nécessairement avoir le droit de lecture sur toute l’arborescence de l’utilisateur, pour lui permettre d’y naviguer. Dans CapDesk, le <em>widget</em> « choix de fichier » est en fait un programme externe auquel l’application fait appel, qui a le droit de naviguer dans les répertoires, et qui renvoie finalement à l’application un simple descripteur de fichier avec les bons droits. Ainsi, l’application n’a pas besoin des droits sur le système de fichiers. Enfin, au lieu d’un simple choix « ouvrir / annuler », on peut afficher, selon les besoins de l’application, « ouvrir en lecture » ou « ouvrir en écriture », pour que l’utilisateur soit mieux conscient des droits qu’il choisit de déléguer à l’application.</p>
<p>Mais les innovations révolutionnaires qui demandent de changer complètement de système d’exploitation, de langage de programmation ou d’environnement de bureau n’ont pas percé (de même que le micro-noyau <a href="http://fr.wikipedia.org/wiki/Micronoyau_L4">L4</a>, [<a href="http://en.wikipedia.org/wiki/Lisp_(programming_language)">Lisp</a>] ou [<a href="http://fr.wikipedia.org/wiki/GNUstep">GNUStep</a>]). Les amateurs de capacités ont alors cherché à « amadouer » (<em>tame</em>) des environnements existants, en les restreignant de façon à pouvoir y garantir les bonnes propriétés des systèmes par capacité. Par exemple, il faut retirer d’un langage de programmation les fonctions qui « ajoutent de l’autorité ambiante », comme les fonctions convertissant un chemin en descripteur de fichier (contient l’autorité entière sur le système de fichiers), ou empêcher les conversions de types trop barbares, qui pourraient permettre de forger une capacité. Entre autres, des versions restreintes des langages <a href="http://fr.wikipedia.org/wiki/Java_%28langage%29">Java</a> (<a href="http://code.google.com/p/joe-e/">Joe-E</a>), <a></a><a href="http://en.wikipedia.org/wiki/Scheme_(programming_language)">Scheme</a>, <a></a><a href="http://fr.wikipedia.org/wiki/OCaml">OCaml</a> ont été proposées. Moins le langage met en avant les variables globales et les effets de bord qui risquent de créer des<br>
<a href="http://fr.wikipedia.org/wiki/Canal_cach%C3%A9">canaux cachés</a>, plus il est facile à rendre « <em>capability safe</em> ».</p>
<p>Récemment, les capacités ont vu un net regain de popularité dans le cadre de la sécurisation du langage de programmation JavaScript. On a encore du mal à y croire, mais ce « langage bricolé » est devenu le standard de fait pour distribuer du code sur internet. Un environnement fortement multi-utilisateur avec distribution et exécution de code dans tous les sens, c’est un mélange explosif pour la sécurité, et de nombreuses failles ont commencé à apparaître ([<a href="http://fr.wikipedia.org/wiki/XSS">XSS</a>]…). Les efforts déployés pour restreindre les sites malicieux (comme le projet <a href="http://developers.facebook.com/docs/fbjs/">FBJS</a> de Facebook) sont mis à mal par les défauts du langage, comme sa gestion abracadabrante des environnements de noms (« <em>scopes</em> »). En utilisant un modèle de capacités, on peut protéger le navigateur et les sites en les aidant à restreindre les droits des scripts exécutés. C’est le thème, entre autres, du prometteur projet <a href="http://code.google.com/p/google-caja/"><em>Caja</em></a> de Google. Les acteurs du Web ont même souhaité prendre en compte ces questions dans les nouvelles versions de JavaScript, et ont invité Mark Miller dans le comité de standardisation, pour proposer des évolutions du langage facilitant l’approche par capacités.</p>
<p>Pour approfondir :</p>
<ul>
<li>
<a href="http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf"><em>Capability Myths Demolished</em></a> (PDF, 15 pages) de Mark Miller, Ka-Ping Yee et Jonathan Shapiro, 2003. Cet article explique les « méconceptions » classiques qui ont fait du tort aux modèles par capacités, comment les corriger. C’est aussi une très bonne présentation des avantages des capacités ;</li>
<li>le <a href="http://www.erights.org/elib/index.html">site du langage E</a>, une mine d’informations (en anglais) sur les concepts sous-jacents, la programmation distribuée et les capacités ;</li>
<li>le projet <a href="http://waterken.sourceforge.net/"><em>Waterken</em></a>, un <em>framework</em> Web basé sur <em>Joe-E</em>, qui a raffiné les concepts de capacités dans le contexte de la programmation Web ;</li>
<li>l’article <a href="http://zesty.ca/pubs/csd-02-1184.pdf"><em>User Interaction for Secure Systems</em></a> (PDF, 16 pages), de Ka-Ping Yee, 2002, montre que négliger l’interface utilisateur, même dans un système respectant le <em>Principle Of Least Authority</em>, peut donner lieu à des problèmes de sécurité ;</li>
<li>l’interview sur <em>InfoQ</em> de Mark Miller, où il discute de son travail dans le comité de standardisation de ECMAscript 5 pour obtenir un langage plus propice à la sécurité : <a href="http://www.infoq.com/interviews/ecmascript-5-caja-retrofitting-security"><em>ECMAScript 5, Caja and Retrofitting Security</em></a>. Il y a une vidéo, mais ne fuyez pas tout de suite, un bonne transcription texte est disponible en dessous. Cliquez sur les petits « + » ou « <em>Full page transcript</em> », en bas, pour voir le texte, et sur les titres pour synchroniser à cet endroit de la vidéo ;</li>
<li>L’article <a href="http://theory.stanford.edu/people/jcm/papers/sp10-camera-ready.pdf"><em>Object Capabilities and Isolation of Untrusted Web Applications</em></a> (PDF, 16 pages) de Sergio Maffeis, John Mitchell, Ankur Taly, qui donne une preuve formelle de la sécurité d’un sous-ensemble de JavaScript (travail qui a permis de trouver des failles dans FBJS), et une autre preuve que le sous-ensemble utilisé par <em>Caja</em> est « <em>capability-safe</em> ».</li>
</ul>
<p>P.S. : John Mitchell a récemment donné un exposé (en anglais) à ce sujet au <a href="https://fr.wikipedia.org/wiki/Coll%C3%A8ge%20de%20France" title="Définition Wikipédia">Collège de France</a>, dans le cadre <a href="http://www.college-de-france.fr/default/EN/all/cha_inf/">du cours sur la sécurité informatique</a> qui y a lieu en ce moment. Des <a href="http://www.college-de-france.fr/media/cha_inf/UPL27176_diaporamaJ._Mitchell.pdf">transparents</a> sont disponibles, et un enregistrement audio devrait l’être bientôt.</p>
<p>C’est aussi une remarque en passant pour dire que, si vous êtes dans la région parisienne et que vous voulez voir la sécurité vulgarisée pour votre grand-mère, ou presque, par des pointures du domaine, n’hésitez pas à passer au Collège de France le mercredi matin (mais attention, la salle est déjà bien remplie).</p>
<h3 id="toc-le-projet-capsicum">Le projet Capsicum</h3>
<p>Le monde du développement Web, bien qu’il croule déjà sous le poids de la rétro‑compatibilité et des standards à rallonge, est encore relativement jeune et peut se permettre des expérimentations de fond.</p>
<p>Du côté des systèmes d’exploitation, l’évolution est moins rapide. Les systèmes d’exploitation actuels n’ont pas beaucoup évolué dans le domaine la sécurité, par rapport aux systèmes UNIX initiaux. Des systèmes plus fins ont été proposés, comme SELinux : l’idée d’ensemble est que ce sont les administrateurs<sup>1</sup> qui décident des politiques de sécurité en écrivant des scripts de « profils » regroupant un petit ensemble de droits, et qui forcent les applications à rentrer dans ces cadres. Malheureusement, ces politiques restent difficiles à écrire, maintenir et déployer, et ces approches n’ont donc pas encore sensiblement amélioré la situation pour les systèmes grand public.</p>
<p>L’approche la plus utilisée est celle des « <em>sandboxes</em> », qui consistent<br>
à compartimenter des applications en utilisant les facilités du<br>
système d’exploitation (<code>« chroot »</code> ou <code>« seccomp »</code>, les <em>jails</em> FreeBSD,<br>
etc.), mais leur gestion des droits est beaucoup moins fine que les<br>
systèmes de capacités, avec souvent des approches « tout ou rien »<br>
(par exemple, <code>« seccomp »</code> interdit tout sauf <code>« read »</code>, <code>« write »</code> et <code>« exit »</code>).</p>
<p>Le projet Capsicum cherche à « amadouer » les appels système, en trouvant un compromis entre la flexibilité-fouillis des capacités (une capacité = un droit) et l’autorité ambiante écrasante des systèmes UNIX habituels. Ses concepteurs ont choisi de raffiner les descripteurs de fichiers UNIX en leur ajoutant des masques de droits permettant une gestion fine des droits (plus de 60 masques différents) auxquels ils sont associés. L’intérêt de réutiliser les descripteurs de fichiers au lieu d’une abstraction dédiée, est de rester dans un style de programmation qui est familier aux programmeurs système UNIX.</p>
<p>Le noyau maintient pour chaque processus un drapeau (<em>flag</em>) booléen qui indique s’il est en « mode capacités » : un programme classique (non sécurisé par Capsicum) ne l’est pas, mais peut choisir d’y entrer avec le nouvel appel système <code>« cap_enter »</code>. Ce drapeau est hérité par tous les processus créés, et ne peut être retiré. Quand le drapeau est activé, tous les appels système exposant de l’autorité ambiante sont interdits, d’autres sont restreints (par exemple <code>« openat »</code>, qui ouvre un fichier à partir d’un répertoire donné, n’accepte plus que les chemins relatifs désignant un fichier dans le sous‑répertoire), et ceux qui restent sont légèrement modifiés pour prendre en compte les masques de droits du descripteur de fichier. Il y a aussi des appels système de bas niveau pour réduire les droits d’un descripteur de fichier, ou lancer un nouveau processus en lui transmettant une partie de ses droits. Enfin, la bibliothèque utilisateur <em>libcapsicum</em> propose des composants de plus haut niveau qui permettent de retrouver le niveau de confort (tout relatif) des programmes systèmes habituels, et les opérations courantes de manipulation de droits.</p>
<p>Les descripteurs de fichiers ne sont pas le seul espace de nom global des systèmes UNIX (malgré les efforts dans ce sens du projet <a href="https://fr.wikipedia.org/wiki/Plan9" title="Définition Wikipédia">Plan9</a>). Les <em>sockets</em> réseau, <em>timers</em> et toutes les interfaces System V et POSIX bizarres pour manipuler, par exemple, la mémoire partagée, sont aussi contrôlés, ce qui est souvent négligé par les solutions de « <em>sandboxing</em> » existantes.</p>
<p>L’idée est de découper les applications en une partie privilégiée, qui tourne avec tous les droits qu’elle avait au lancement, et une ou plusieurs parties compartimentées, qui sont sous un appel à <code>« cap_enter »</code> avec exactement les droits nécessaires. Le but du jeu est que toutes les parties sensibles (en C, la manipulation de chaînes) soient compartimentées et que la partie privilégiée réalise le moins de choses possibles, ceci afin de réduire la surface d’attaque. Plus le découpage est fin, plus le logiciel respecte le <em>Principle of Least Authority</em>. Et la sécurité en est d’autant renforcée.</p>
<p>(1) : Plus généralement, les approches par <em>Mandatory Access Control</em> (SELinux) et par capacités sont complémentaires : le MAC vise à permettre à un administrateur système de contrôler les droits selon les besoins de son environnement, alors que les capacités servent<br>
au développeur pour contrôler les droits selon les besoins de son application.</p>
<p>En savoir plus :</p>
<ul>
<li>la <a href="http://www.cl.cam.ac.uk/research/security/capsicum/">page du projet <em>Capsicum</em></a> au laboratoire sécurité de l’université de Cambridge (GB) ;</li>
<li>les <a href="http://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811-usenix-capsicum.pdf">transparents de la présentation</a> (PDF, 31 pages) donnée à la conférence de sécurité <em>USENIX</em> en août dernier ;</li>
<li>l’article « <a href="http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf"><em>Capsicum: practical capabilities for UNIX</em></a> » (PDF, 17 pages), par Robert Watson et Jonathan Anderson (Cambridge), Ben Laurie et Kris Kennaway (Google UK). Cet article contient une explication plus détaillée de Capsicum (logique !), mais aussi des rapports d’expériences sur des essais de sécurisation de logiciels existants, et des mesures de performance pour évaluer le surcoût associé à ces modifications. Je les décrirai brièvement dans la prochaine partie, mais si vous voulez des détails, il faut aller lire ce papier. Enfin, l’article contient des comparaisons aux solutions existantes : si vous vous dites « mais, c’est pareil que SELinux / chroot / PLASH ! », il faut aller lire ça.</li>
</ul>
<h3 id="toc-et-ça-marche">Et ça marche ?</h3>
<p>Les gens de Google qui travaillent sur le navigateur Chromium se sont montrés très intéressés par le projet Capsicum. En effet, Chromium essaie de mettre en place des mécanismes de « <em>sandboxing</em> », ce qui a forcé les développeurs à évaluer les différentes solutions existant sur les principaux OS (Windows, Mac OSX, GNU/Linux, BSD…). Ils ont découvert qu’aucune solution n’est complètement satisfaisante : soit les droits sont trop grossiers, rigides ou difficiles à configurer (Sandbox de MacOS X, SELinux), soit les droits sont très restreints et il faut alors implémenter soi‑même une couche de médiation en utilisant un processus ayant plus d’autorité. Ainsi, la solution de confinement sous Windows et celle utilisant <code>« seccomp »</code> sous GNU/Linux ont demandé des dizaines de milliers de lignes de code supplémentaires, sans pour autant obtenir exactement les droits désirés… Capsicum leur a permis, en modifiant seulement une centaine de lignes de code, de mettre en place une <em>sandbox</em> flexible et répondant à leurs besoins.</p>
<p>Les développeurs de FreeBSD se sont aussi montrés intéressés par la technologie Capsicum, et se préparent à l’inclure dans la prochaine version de FreeBSD. Évidemment, comme Capsicum demande des modifications des appels système du noyau sur des points plutôt sensibles, il faut réussir à convaincre les développeurs de chaque noyau qu’inclure ces modifications vaut le coup… La communauté NetBSD a eu l’air plutôt favorablement intéressée, et un portage pour Linux serait en développement, mais l’inclusion en amont dans ces systèmes n’est pas encore d’actualité.</p>
<p>Du côté des autres applications, les développeurs de Capsicum ont converti les programmes <code>« tcpdump »</code>, <code>« dhclient »</code> (tous deux déjà responsables de vulnérabilités liées au traitement des chaînes de caractères, et déjà partiellement compartimentés en utilisant d’autres technologies moins fines) et <code>« gzip »</code>.</p>
<p>Ci‑dessous, les 8 lignes de sécurisation du <a href="http://svn.freebsd.org/viewvc/base/projects/capabilities8/contrib/tcpdump/tcpdump.c?revision=208660&view=markup&pathrev=208660">code de <code>tcpdump</code></a>. On commence par restreindre l’autorité ambiante des descripteurs de fichiers standard : on ne pourra plus utiliser que <code>« fstat() »</code> sur « <em>stdin</em> ». La fonction <code>« lc_limitfd() »</code> provient de <a href="http://code.google.com/p/capsicum-core/"><em>capsicum-core</em></a>, bibliothèque en espace utilisateur. Ensuite on passe en mode capacités avec <code>« cap_enter »</code>. À partir de ce moment, les paquets reçus seront analysés (opération sensible) dans un environnement à autorité minimale.</p>
<blockquote>
<pre><code>if (lc_limitfd(STDIN_FILENO, CAP_FSTAT) < 0)
error("lc_limitfd: unable to limit STDIN_FILENO");
if (lc_limitfd(STDOUT_FILENO, CAP_FSTAT | CAP_SEEK | CAP_WRITE) < 0)
error("lc_limitfd: unable to limit STDIN_FILENO");
if (lc_limitfd(STDERR_FILENO, CAP_FSTAT | CAP_SEEK | CAP_WRITE) < 0)
error("lc_limitfd: unable to limit STDERR_FILENO");
if (cap_enter() < 0)
error("cap_enter: %s", pcap_strerror(errno));
</code></pre>
</blockquote>
<p>Les leçons tirées de ces expériences sont multiples. D’une part, les développeurs ont pu observer que sur une application réelle, le surcoût en performance lié au « <em>sandboxing</em> » est « assez » faible (moins de 10 % dans les cas défavorables, et un petit surcoût constant en général). Il y a quand même un coût qu'ils essaient de réduire en optimisant leur implémentation. Paradoxalement, Capsicum est moins coûteux que d’autres solutions de « <em>sandboxing</em> », donc, en convertissant un logiciel déjà compartimenté vers Capsicum, on peut en améliorer légèrement les performances, en plus d’obtenir une gestion plus fine des droits.</p>
<p>D’autre part, ils ont constaté que les applications qui reposaient déjà sur un modèle compartimenté avec « <em>sandboxing</em> » étaient extrêmement faciles à convertir vers Capsicum. Mais, le cas d’applications grand public n’ayant aucune expérience de séparation des privilèges risque d’être plus délicat…</p>
<p>La grande force de Capsicum par rapport aux autres solutions utilisant les capacités, c’est qu’il s’agit d’un raffinement, et non d’un remplacement, des systèmes de droits UNIX usuels : on peut convertir les applications une par une, et même module par module. Une mise en œuvre progressive, concentrée sur les applications sensibles, est donc possible. Mais il faut quand même motiver les développeurs à prendre ces problématiques en compte.</p>
<p>À quand Capsicum disponible sur Linux, et LibreOffice, Firefox et KDE respectant le principe de moindre autorité ? Qui s'y colle ?</p>
<p>Plus de détails croustillants :</p>
<ul>
<li>la <a href="http://lists.freebsd.org/pipermail/freebsd-arch/2011-January/011081.html">discussion sur la liste FreeBSD</a> en vue d’une intégration dans la 9.x. <a href="http://lists.freebsd.org/pipermail/freebsd-arch/2011-January/011084.html">Ce message</a>, en particulier, contient des comparaisons à d’autres solutions de sécurité ;</li>
<li>Capsicum est <a href="http://www.freebsd.org/news/status/report-2010-07-2010-09.html#Capsicum:-Practical-Capabilities-for-UNIX">mentionné dans le rapport d’activité</a> FreeBSD, avec un plan plus détaillé d’intégration dans FreeBSD ;</li>
<li>le <a href="http://mail-index.netbsd.org/tech-kern/2010/09/24/msg008874.html">fil de discussion</a> des gens de NetBSD au sujet de Capsicum ;</li>
<li>deux messages (en <a href="https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2010-June/msg00000.html">juin</a> et en <a href="https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2011-January/msg00000.html">janvier</a>) de Heradon Douglas, un ingénieur Google qui travaille à un portage Linux sur ses 20 % de temps libre. On est encore loin d’une intégration en amont…</li>
</ul>
</div><div><a href="https://linuxfr.org/news/capsicum-une-separation-fine-des-privileges-pour-unix.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/85224/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/capsicum-une-separation-fine-des-privileges-pour-unix#comments">ouvrir dans le navigateur</a>
</p>
bluestormhttps://linuxfr.org/nodes/85224/comments.atom