Il est grand temps qu’Android évolue en scindant son “noyau” en plusieurs parties. Il y a trop de choses dedans (à commencer déjà par les applis préinstallées non désinstallables, y compris les applis Google comme le Google Play Store ou Youtube, qui buffent la place en permanence dans leur ancienne version, même quand on a installé la nouvelle version en plus).

 Même les bibliothèques de service (non strictement nécessaires au démarrage de l’appareil ou les pilotes de périphériques tels que la Cam) devraient être isolés dans des packages TOTALEMENT désinstallables (pour libérer l’espace interne et pour ne plus avoir à les réactiver si on a mis autre chose pour les remplacer).

Même les pilotes de périphériques (y compris les “blobs” propriétaires devraient être remplaçables, il suffirait juste d’un certificat de sécurité pour installer la nouvelle version puis une fois activée et fonctionnelle supprimer totalement l’ancienne).

 Et dans la plupart des cas cela ne devrait même pas nécessiter de rebooter le téléphone ou d’installer une nouvelle ROM de base. Je ne comprends pas du tout pourquoi toutes les ROM sont aussi énormes, même débarassées du package additionel des GoogleApps à installer séparément). La ROM doit juste permettre d’énumérer les périhpériques physiques de base, aucun périphérique purement logiciel ne devrait y être (exemple les méthodes de saisie, les listes de certificats préapprouvés, beaucoup trop grosses alors qu’il suffit d’inclure dans la ROM un unique certificat identifiant la version de la ROM ou sa source officielle pour permettre de la mettre à jour avec éventuellement un nouveau certificat, les autres certificats sont téléchargeables ensuite depuis le site du fournisseur, même si la package d’installation en ajoute dès le début dans la zone non protégée)

 

Mais il semble en fait que les APIs spécifiques Android (hors des API Java classiques) soient uniquement des créations de Google permettant aux applis Google de communiquer librement entre elles en passant outre leur barrière d’isolation, elles sont là non pas comme des barrières mais comme des portes ouvertes. Libstragefright en est un parfait exemple puisqu’elle change silencieusement de contexte de sécurité et passe toutes les données qu’elle veut d’un niveau à l’autre :



Un unique point de contrôle est mis à l’entrée de l’API mais tous les composants utilisés derrière ne vérifient plus rien, ils sont déjà en mode privilégié et Google se passe totalement dans ses APIS d’utiliser les APIs documentées des autres composants, ce qui est une violation du concept de boite noire : il y a trop de passerelles dérobées, ces bibliothèques n’étant pas isolées entre elles, la boite noire est juste superficielle (c’est juste un bout de chiffon noir posé sur un plat de vieilles spaghettis grouillant de vers : on croit voir la fine couche de fromage gratiné, ça sent bon et on plonge la cuillère dedans, on croit se régaler et on finit par une bonne tourista) Le problème est que lors du passage interne d’une bibliothèque à l’autre, on a perdu la trace du contexte de sécurité d’origine (car Google ne respecte pas les consignes de sécurité Java et ne transmet pas les contraintes en créant les contextes appropriés: il passe toute les données en aveugle à la bibliothèque suivante sans même savoir si c’est vraiement elle qui va les traiter et pas une autre encore plus bas et ces canaux internes ne valident pas chaque étape.

 





 Il faut dire aussi que le cas des codecs multimédia (objet de Libstagefright) est à la base un plat de spaghettis avec de trop nombreuses extensions non documentées. Les spécifications d’ailleurs sont largement incomplètes, et les extensions possibles beaucoup trop nombreuses. La notion de “profil” des extensions supportées n’est pas mise en oeuvre du tout alors qu’un profil devrait bloquer tout ce qu’il ne connait pas ou n’implémente pas (ou pas encore) correctement et complètement (pour utiliser les extensions, il faudrait non seulement transmettre les données mais aussi l’identification du profil de sécurité afin que l’extension de plus bas niveau ait de quoi faire des vérifs supplémentaires et valider les droits accordés ou pas.

 

Et puis il faut en finir avec les trop nombreuses versions d’Android qui ne sont maintenues que par les constructeurs ou vendeurs de réseaux mobiles. On veut un OS unique avec une mise à jour unifiée des composants de base. Les vendeurs peuvent inclure ou pas une bibliothèque option elle, mais s’ils l’incluent cette blibliothèque doit pouvoir être mise à jour séparément depuis leur source réelle et non pas l’assembleur de la ROM.

 



 La ROM critique de base ne devrait même pas avoir de navigateur intégré et ne contenir qu’un jeu simplifié d’algorithmes de sécurité (SHA3, DES, RSA, AES) si possibles supportés par le matériel uniquement pour valider l’image du noyau (uniquement ce qui est nécessaire dans le bootloader), tout le reste au dessus devrait utiliser ses propres algos ou extensions désinstallables, cela ne devrait jamais être permanent dans une ROM même si c’est installé dans des sandbox virtualisées.