Journal Tame et OpenBSD

Posté par (page perso) . Licence CC by-sa
66
20
juil.
2015

Juste un petit journal pour vous signaler un post intéressant de Theo de Raadt (leader d'OpenBSD) sur la liste "Tech".
Dans ce post il présente tame, un outil sur lequel il travaille depuis un certain temps et qui vise à réduire les droits d'un programme afin de diminuer la surface d'attaque.

Theo commence par évoquer très brièvement les alternatives et pourquoi, selon lui, elles ne conviennent pas.

  • Capsicum nécessite de réécrire profondément le programme qui sera protégé.
  • D'autres approches (...)

Capsicum dans Linux : ça bouge !

Posté par . Édité par Benoît Sibaud, Xavier Teyssier et Nils Ratusznik. Modéré par Nils Ratusznik. Licence CC by-sa
42
4
août
2014
Sécurité

Capsicum a été évoqué sur LinuxFr.org une première fois en 2011. C'est un projet de chercheurs de Cambridge concernant de nouvelles primitives de gestion des droits pour les systèmes UNIX, très prometteur et en passe d'être intégré à FreeBSD.
Voyons quels sont les mouvements autour de ce projet.

Logo Capsicum

Journal Capsicum dans Linux : ça bouge !

46
3
août
2014
Ce journal a été promu en dépêche : Capsicum dans Linux : ça bouge !.

Chers LinuxFrien-ne-s,

En 2011 je vous parlais de Capsicum (dépêche LinuxFr), un projet de chercheurs de Cambridge de nouvelles primitives de gestion des droits pour les systèmes UNIX, très prometteur et en passe d'être intégré à FreeBSD.

Linux n'avait à l'époque pas de bonne solution pour un sandboxing fin; en 2012, une revue complète du système seccomp (dépêche LinuxFr) apportait un mécanisme très fin de contrôle des appels systèmes, mais ne gérant pas le transfert de (...)

Journal Seccomp, une sandbox intégrée au noyau Linux…

44
4
mai
2014

Problématique

Utilisez-vous pour vos développements professionnels ou privés une solution d'intégration continue à la Jenkins ? Un tel logiciel permet d'accélérer le développement du code en le testant plus régulièrement, en le soumettant automatiquement à des tests unitaires.

Mais que se passe-t-il si un vilain© soumet du code dangereux pour votre système d'intégration continue ? Si votre logiciel d'intégration continue se contente de compiler du code, vous pensez qu'il est protégé ? Quid d'une faille dans votre compilateur, ou d'un problème à l'exécution (...)

Journal Un article sur le sandboxing de Chrome sous Linux

Posté par .
21
8
sept.
2012

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 (...)

Sandboxing fin dans le noyau linux : la saga des filtres seccomp

77
15
jan.
2012
Noyau

Les développeurs de Google sont toujours à la recherche de solutions permettant d'améliorer la sécurité du navigateur web Google Chrome (ou son implémentation libre Chromium), ou de leur projet ChromeOS. Dans la dépêche à ce sujet, je vous avais raconté leur participation au projet Capsicum, qui apporte une gestion très fine des privilèges d'un processus, maintenant intégré dans FreeBSD.

Bien que les techniques mises en place par Capsicum soient pensées pour tous les systèmes inspirés d'UNIX, il n'y a pas grand espoir aujourd'hui qu'un port Linux soit accepté par les développeurs noyau ; Capsicum est un projet externe qu'il faudrait d'abord intégrer, ré-exprimer en terme des fonctionnalités existantes dans le noyau ; et les mainteneurs sont notoirement mécontents de la multiplication des solutions de sécurité (les Linux Security Modules en particulier) et ne verraient pas d'un bon œil l'apparition d'un nouveau candidat. Les développeurs Chromium utilisent sous Linux le primitif système de sandboxing seccomp, bien qu'il soit beaucoup moins flexible que Capsicum et donc nettement plus pénible et difficile à utiliser.

Depuis 2009, les développeurs Chrome essaient d'étendre les capacités de seccomp pour mieux répondre à leurs besoins. Les changements se sont révélés beaucoup plus difficiles à faire accepter que prévu : la situation a semblé bloquée à de nombreuses reprises et n'a pas évolué pendant de nombreux mois. Après plusieurs tentatives infructueuses, Will Drewry vient de proposer une nouvelle approche qui pourrait obtenir l'approbation des développeurs noyau ; mais rien n'est encore gagné…