jeudi 19 janvier 2012

SE Android, le dilemme d'un Android NSA

La fameuse NSA (National Security Agency) ne participe pas qu'à des opérations clandestines nourrissant nombre de fantasmes, à tort ou à raison. Si son rôle est de garantir une certaine infodominance, elle est chargée avant tout de la sécurité des communications militaires et gouvernementales et, plus largement, de la protection des systèmes et des infrastructures de communication mis en œuvre sur le territoire américain. Sans compter ses prérogatives extrêmement confidentielles en matière de collecte d'informations, multi-supports et de niveau mondial.

L'une de ses autres missions, capitale, est de pouvoir apporter les meilleurs garanties  possibles en termes d'Assurance de l'Information. C'est dans ce cadre qu'elle agit pour améliorer des produits accessibles à tous, comme des systèmes d'exploitation et des applications. Elle édite des guides de recommandations et les spécialistes noteront sa prédilection concernant le durcissement des OS. L'un des projets phare s'appelle Security-Enhanced Linux (SE Linux) et il a la particularité d'être ancien (plus d'une décennie) et d'avoir profité à l'ensemble de la famille du fameux pingouin (de Solaris jusqu'à FreeBSD, c'est dire ;)

Parmi les mécanismes proposés, se trouve Flask qui, malgré son nom ne l'est pas !  C'est une architecture flexible qui permet l'accès aux ressources par l'application fine des accès logiques et des droits associés en fonction de la politique de sécurité retenue et en tenant compte de deux critères essentiels : la confidentialité et l'intégrité des données. Autrement dit, Flask est la déclinaison aboutie mais aussi plus élaborée du Contrôle d'accès obligatoire (MAC ou DAC). Plus élaboré car le système va plus loin que du "simple" contrôle d'accès puisque reposant sur une architecture modulaire, il dispose de fonctions de  contrôles "internes" sur plusieurs niveaux et permet jusqu'à l'isolation d'une zone contenant une faille logicielle ou causée par une attaque malveillante !

Lors du Linux Security Summit l'été dernier, un projet focalisé sur Android avait été présenté. Retombée directe du prolifique projet SE Linux, la v1 de SE Android vient d'être officiellement annoncée en début de semaine. Il faut cependant souligner les deux écueils, l'un technique l'autre de confiance. La difficulté technique concerne l'installation de cette version qui n'est pas simple. Pour qui utilise Windows, il faut disposer d'un environnement Linux et le préparer. Ensuite, il faut suivre les indications du wiki du projet (premier lien de ce paragraphe). L'interrogation plus générale concerne le niveau de confiance que tout un chacun est en droit d'attendre d'un système d'exploitation sponsorisé par l'une des plus grandes agences de renseignement au monde (si ce n'est la première). 

Je renvoie à ce titre au thread sur le sujet que l'on trouve sur linuxfr.org (que je salue au passage). Parmi les échanges intéressants, celui sur la double compilation et les méthodes pour cacher quelques lignes de code à visées malveillantes (backdoor), invisibles même en cas d'audit de code approfondi, m'apparaissent significatifs. Des deux maux, un Android standard (potentiellement vulnérable) et un Android durci (mais avec une possible backdoor NSA),  lequel choisiriez-vous ?

2 commentaires:

CIDRIS a dit…

Bien vu ! Il existe des méthodes un peu du même genre présentée au C&ESAR 2011..: un recensement des stricts besoins des applications associées à des contrôles d'accès...

Peut-être une bonne solution intermédiaire ?

Sur SELinux, je n'ai que très peu d'expérience perso mais les retours que j'ai sont assez unanimes sur la difficulté à mettre en place et à gérer...

Si vis pacem a dit…

Merci pour ton commentaire Cidris. La solution intermédiaire dont tu parles à un intérêt certain même si on peut considérer que l'architecture Flask est d'un niveau supérieur. Mon seul "souci", et c'est l'objet de cet article, c'est de savoir si SE Android est sain où s'il comporte des surprises. Un audit de code poussé par un centre spécialisé permettrait sans doute d'y répondre...