Personnellement je suis un peu sceptique vis-à-vis de sysbox, qui si je ne me trompe pas, repose surtout sur l'utilisation de user namespaces (comme rootless et podman). Le problème des user namespaces c'est que depuis des années on se rend compte que son code (privilégié de surcroît) est problématique et qu'autoriser son accès à des utilisateurs standards est généralement une mauvaise pratique. Et si je ne me trompe pas, avec sysbox, les appels systèmes sont toujours satisfaits par le kernel hôte.
En l'occurrence, Docker Desktop isole l'ensemble des conteneurs dans une VM, mais du coup je doute toujours de l'intérêt de sysbox par rapport à runc + usersn-remap si quelqu'un veut faire la même chose. Je pense que la meilleure approche à terme serait une solution similaire à ce que fait Google avec gVisor (qui fournit un runtime OCI-compliant), qui n'est pas sans défauts mais qui mérite le coup d'oeil.
Tout à fait, Android a fait un long chemin ! Il devient au fur et à mesure une référence en matière d'OS robuste pour la sécurité et la vie privée, sans sacrifier à l'usage. Et en plus, c'est open-source : peut-être pas "libre" au sens où la communauté de LinuxFr l'entend au sens où il y a peu de place à la contribution communautaire, mais open-source quand même. Je pense que c'est un plus, je le décris même dans mon idéal de la sécurité basée sur l'évidence soutenue par la fameuse Zero Trust Security comme diraient les anglophones.
Quant au Play Store, vous avez le droit de soulever des problématiques à l'encontre de ce service. Le but de cet article n'est pas de glorifier l'usage du Play Store, en fait, je le compare dans certains aspects à F-Droid pour mettre à mal ce dernier. Oui, ça fait mal, c'est normal. Mais ici il n'est pas question de manquer de respect à une éthique ou une culture (libre en l'occurence) quelle qu'elle soit : vous pouvez même voir cet article comme une contribution. Tout est question de perspective. Pour ma part, j'ai choisi de mettre en lumière ces défauts et de contribuer à une alternative qui reprendra depuis le début avec des choix radicalement différents, expliquant que je ne puisse pas contribuer à F-Droid directement. Mais je leur souhaite tout le meilleur, vraiment.
Pour revenir au Play Store, oui, il est loin d'être parfait. Oui, des questions de vie privée ont parfaitement le droit de se poser dès lors qu'un compte est demandé pour accéder à un service essentiel sur Android. Rien de tout cela n'est remis en question, je comprends l'existence de F-Droid. Je mentionne même que je conseille l'utilisation du Play Store sur GrapheneOS car il n'y est pas privilégié, dans le sens où je ne serais moi-même pas forcément à l'aise si je venais à l'utiliser sur un autre OS qui l'intègre dans une sandbox dédiée moins restreinte. GrapheneOS illustre parfaitement que c'est possible, et Google aurait dû le faire comme ça : oui, les services Play (même reproche fait à microG) affaiblissent aussi dans un sens le modèle de sécurité d'Android.
Pour finir, il faut évidemment considérer la sensibilité de chacun : son modèle de menace, sa culture, ses préférences. Mais parfois, certaines analyses froides sont nécessaires, justement pour informer un maximum de personnes, les aider dans ce choix, et contribuer in fine à développer des solutions respectueuses sur tous les plans. C'était simplement mon intention, je comprends qu'elle puisse susciter de vives réactions car j'ai occulté des aspects importants qui méritent vraiment d'autres articles.
Je vais faire fi de la simplification douteuse que vous faites de ma vision de la sécurité, car non, ça ne se résume pas à une "chaîne de confiance cryptographique". Il ne faut pas tout mélanger, même si effectivement ce journal était déjà la preuve d'un désaccord fondamental.
Vous partez également du postulat que la disponibilité publique du code source est une nécessité pour être audité. C'est simplement faux, ce serait oublier que le code source peut être disponible sur demande, que l'ingénierie inverse existe, et plus particulièrement dans le domaine dans le sécurité des outils comme le fuzzing et les MITM. Avoir le code source c'est bien, mais étudier le code qui est distribué, c'est tout à fait possible. Ce billet résume assez bien ma pensée : https://seirdy.one/2022/02/02/floss-security.html
Il n'y a rien à voir avec une "solution cryptographique" là-dedans, c'est simplement comment les choses fonctionnent dans la vie réelle.
Alors accuser F-Droid de “weakening the Android security model”, ouais, c’est biaisé et un peu génant quand même. De toutes les applis signées par leurs développeurs disponibles sur le Play Store, il n’y en a pas beaucoup que j’installerais sans craindre pour la sécurité de mes données et de ma vie privée.
Biaisé par rapport à votre vision de la sécurité informatique, peut-être, mais certainement pas biaisé par rapport à la documentation qui fait état du modèle de sécurité d'Android et des device/user management APIs qui considèrent qu'un store = une source et pas autrement. F-Droid court-circuite fondamentalement cela. Il n'y a rien de compliqué à comprendre, et ça n'a rien à voir avec le débat que j'évoque ci-dessus en soi. Je veux idéalement des solutions FOSS qui ne font pas des compromis qui ne sont pas nécessaires.
Sur un site avec un lectorat (au moins en grande partie) libriste, forcément ça passe mal.
Je n'ai jamais demandé à ce que mes articles soient publiés ici, car je sais d'avance que le lectorat libriste a ses propres valeurs qui ne sont pas les miennes. Bien évidemment, je ne peux contrôler comment mes articles sont partagés donc encore une fois, je n'en veux pas aux personnes de mal réagir. Je déplore simplement une perte de temps des deux côtés, et, de mon côté en tout cas, parfois de la stupéfaction et de la déception.
Nous avons effectivement des référentiels de pensée différents, peut-être opposés (nous ne sommes pas allés dans le détail non plus), et vraiment je n'ai aucun problème avec cela. La diversité d'opinions est une bonne chose. Malgré tout, je ne pense pas que tout peut être relativisé. Il y a des faits dont peut vérifier l'authenticité. Je ne dis pas que mes articles sont dépourvus de biais, car évidemment des biais même inconscients peuvent se glisser dans ma façon d'agir. J'essaie quand même au maximum de promouvoir les analyses objectives, qui sont parfois froides, mais nécessaires. Je vais essayer d'expliquer brièvement ma pensée sur le sujet.
Pour remettre dans le contexte, Android est un système d'exploitation moderne qui se démarque des autres systèmes traditionnels par son application des bonnes pratiques, notamment un écosystème d'applications signées qui sont contenues dans des sandbox très restreintes. Ce dernier permet l'établissement d'un modèle de permissions qui se modernise au fur et à mesure des itérations d'Android. Ce sont les garanties "fortes" dont je parle. Si je souhaite qu'une application n'ait pas accès à mes contacts, elle ne doit pas avoir accès. Si je souhaite qu'elle ait accès à un dossier, je lui donne la permission pour ce dossier seulement.
Je pense effectivement que la disponibilité du code source ne doit pas être une préoccupation majeure dans le cadre d'une approche pragmatique (et pas forcément éthique), tant le code source peut être complexe à comprendre et auditer. De plus, les applications Android sont souvent précompilées en bytecode Dalvik, qui peut toujours se soumettre à l'ingénierie inverse. Le modèle de développement d'un logiciel quel qu'il soit ne doit pas être un feu vert automatique pour savoir que ce dernier fait seulement ce qu'on attend de lui, ou ne contient pas de code vulnérable inconnu du développeur. C'est pour cela que j'insiste sur les garanties fortes permises par des OS modernes. Je vous assure qu'elles sont suffisantes pour l'écrasante majorité des cas, il incombe ensuite à l'utilisateur de décider des permissions à accorder. Les permissions invasives ne sont jamais octroyées par défaut sur de tels OS.
Pour revenir à F-Droid : par leur "contrôle qualité offrant peu de garanties", j'entends que beaucoup de personnes se contentent de F-Droid en tant qu'autorité pour déterminer si une app est sûre ou non. La réalité est que F-Droid n'audite en rien le code source, et lance simplement des scripts pour chercher des trackers connus ; ce qui encore une fois, est une approche que je trouve faible. J'insiste donc sur le fait que F-Droid est une partie intermédiaire qui ne se substitue en rien à la confiance au développeur upstream. Et on ne peut pas leur en vouloir, il n'est pas raisonnable de se lancer dans des audits de code source qui sont humainement laborieux et imprécis.
Je propose donc de placer cette confiance, pour ceux qui souhaitent suivre une approche pragmatique encore une fois, dans le modèle de sécurité robuste de l'OS. C'est évidemment encore mieux sur GrapheneOS qui ajoute un toggle permettant de révoquer la permission INTERNET (coupant cout les tentatives d'exfiltration), et un autre permettant de fournir des données de capteur nullifiées. Mais même Android upstream s'améliore comme dit : cf. les permissions Nearby Devices, et l'ajout à venir d'un sélectionneur granulaire de photo dans MediaProvider, le scoped storage en vigueur depuis le niveau d'API 30. Même s'il y a exfiltration, l'application ne peut avoir accès qu'aux permissions qu'on lui donne à la base, et donc à des types de données précis. Il est tout à fait possible qu'en pratique les applications open-source soient plus enclines à respecter la vie privée. Cependant, je propose tout simplement de ne pas placer cette forme de confiance tout en haut de la hiérarchie, car elle relève de l'appréciation personnelle et du modèle de menace de chacun.
Je n'ai évidement aucun problème avec le logiciel libre et la culture libre dans son ensemble. Il est vrai qu'à titre personnel je ne m'y reconnais plus bien qu'elle ait bercé mon adolescence (je lisais d'ailleurs linuxfr depuis plus de 10 ans), et je lui dois la découverte de nombreux projets. Dans cet article je m'adresse seulement à des faiblesses de F-Droid, et je souhaite réellement voir émerger d'autres alternatives plus en accord avec le modèle de sécurité pensé par et pour Android, qu'elles viennent de GrapheneOS ou d'ailleurs. Les gens sont libres de continuer à utiliser F-Droid, de leur faire confiance, j'expose simplement quelques problèmes dont certains peuvent être réglés par F-Droid pour le bénéfice de tous.
Auteur ici. J'apprécierais (vraiment) si l'on évite les rapprochements douteux avec des opinions politiques, car si certains pensent que chacun est politisé, les actions ne le sont pas forcément. L'écriture de cet article n'a aucune motivation politique, mais elle suit effectivement une démarche personnelle et n'a pas eu vocation à être partagée massivement.
J'explique justement, parfois en longueur, mon approche pragmatique de la vie privée. Je n'incite pas à se livrer en pâture à Google ou n'importe quelle big tech sans raison. Je demande simplement que l'on regarde objectivement les défauts des solutions FOSS actuelles, ce qu'on peut faire de mieux, et de potentielles alternatives.
la seule autorité de confiance ici c'est F-Droid, et avec elle, je sais que je vais avoir la fameuse seconde version sans la pomme empoisonnée sur le gâteau
C'est faux, et je ne sais pas pourquoi ce mythe est souvent répandu de la même façon pour les paquets des distributions classiques Linux. L'article explique justement que ce principe ne tient pas la route et que vous devez quoiqu'il arrive faire confiance aux développeurs upstreams, et que pour votre vie privée, vous avez davantage intérêt à faire confiance aux garanties offertes par l'OS qu'une vérification très basique du code source (et je suis gentil). C'est juste, à mon sens, du bon sens. Encore une fois, je suis tout à fait compréhensif de la culture libre, mais ce n'est vraiment pas la vision de cet article.
Encore une fois, j'aimerais que les réponses soient plus pertinentes que des "meh biais/sophisme" sans prendre la peine de bien lire les articles et ses références, bien qu'il est évident que nous avons un désaccord de principe (et ce n'est pas la fin du monde, il y a bien pire qui se passe actuellement).
Ensuite pour déverrouiller le bootloader, il faut un accès à l'enclave sécurisée (cf. le post sur le byte OEM unlocking), bonne chance pour le faire sur un Pixel. Ensuite le fait de déverrouiller le bootloader supprime toutes les données, entre autres par une clé de dérivation utilisée en tant qu'input pour le FBE. Ce que tu décris n'est déjà pas possible, mais sera remarqué par l'utilisateur final (et pas qu'un peu !).
Je pense que tu te méprends totalement sur l'intérêt d'un bootloader verrouillé et d'AVB. Merci de ne pas écrire de la désinformation, il y en a déjà beaucoup trop sur la toile… :(
Ce n’est pas tout à fait ça. Sur les Google Pixel par exemple, l’autorisation du déverrouillage est contrôlée par un byte présent sur l’enclave sécurisée, typiquement le TEE (TrustZone) ou un élément sécurisé. Ces enclaves sont particulièrement isolées du reste du système, pour le dire simplement. Les appareils plus négligents stockent ce byte sur une partition, inutile de dire que ça ne protège pas vraiment.
Ce byte est contrôlé par le paramètre OEM unlocking dans les options de développeur sur Android. C’est en fait l’étape finale de l’installation de GrapheneOS ou encore CalyxOS sur Pixel, mais aussi l’étape initiale pour permettre de déverrouiller puis procéder à l’installation de ces images qui sont signées effectivement (mais pas forcément par Google). Pour que Android Verified Boot puisse fonctionner, il faut flasher en effet des clés customs, justement pour cette raison (signées par l’auteur de l’OS en question).
Une fois l’installation finie, on verrouille le bootloader puis on change le byte avec le paramètre OEM unlocking une fois dans Android. Concernant la crainte sur le problème de maj, comme expliqué dans mon article, il y a un système de double partitions au moment de la mise à jour. Au bout de X tentatives ratées, rollback vers la précédente version fonctionnelle.
Comme je l’ai dit, le channel Matrix est ouvert à tous. Tu peux poser la question, tu auras la même réponse. Pour les détails, tu peux consulter les logs Freenode (tant que c’est encore possible…).
Je n’ai jamais dit que cette implémentation minimale est magique. Elle pourrait juste aider quelques applications, mais ça ne remplace certainement pas FCM, SafetyNet ou toute la suite d’API Google. Nous sommes d’accord. Il faut tout simplement des fallbacks, des alternatives à ces services prévues par les développeurs ; ou bien des applications qui en font complètement l’impasse.
Dans les faits, pour utiliser des versions d’Android sans Play Services ou apparenté depuis des années, beaucoup d’applications même incompatibles sur le papier fonctionnent. J’en fais part en détails dans mon article dont le lien est dans la dépêche.
Bonjour, j'ai partiellement répondu à cette question dans certains commentaires. Je me permets de plus ou moins le faire si ça ne dérange pas. :)
Entre autres, un bootloader déverrouillé permet à n'importe quel attaquant physique (on parle de simple "possession" du smartphone) d'exécuter des commandes privilégiées qu'il ne devrait pas pouvoir faire (fastboot et adb). Il permet par exemple d'installer un rookit (un malware persistant), de faire une copie des partitions (les effacer aussi, mais c'est "moins" grave), de pouvoir mener des attaques qui peuvent aller jusqu'à compromettre les données malgré le FDE/FBE (chiffrement de disque/profil). Ce n'est pas alarmiste, ce n'est même pas seulement à la portée d'un attaquant sophistiqué, c'est juste la pierre angulaire du modèle de sécurité mobile.
Android a également cette mitigation que l'on appelle verified boot, c'est la vérification d'intégrité au démarrage du firmware et de l'OS. Elle ne peut pas, par nature, fonctionner avec un bootloader déverrouillé. Elle permet non seulement de lutter contre des attaques physiques mais aussi à distance : les persistances peuvent être détectées, l'idée est de ne jamais démarrer un système compromis et dont il est impossible de retrouver l'état d'intégrité. Le verified boot n'est bien entendu pas propre à GrapheneOS, il est propre à Android mais la plupart des constructeurs en ont une mauvaise implémentation (pour ne pas dire qu'elle ne fonctionne pas). iOS l'a aussi, d'ailleurs.
En d'autres termes, le déverrouillage du bootloader doit être une étape temporaire uniquement lors de l'installation d'un OS custom. L'installateur WebUSB de GrapheneOS l'explique assez bien d'ailleurs, mais n'hésite pas à rechercher pour plus d'informations.
c’est une protection contre l’injection de code malveillant sur ton téléphone via un accès physique
Il est bon de rappeler que la vérification d'intégrité au démarrage (permise par un bootloader verrouillé) n'est pas "juste" une protection contre les menaces physiques mais aussi une protection générale comme des formes de rootkits quelles qu'elles soient. C'est une mitigation importante pensée dans le modèle de sécurité d'Android, ce n'est pas quelque chose de GrapheneOS, mais c'est quelque chose dont les autres distributions d'Android sont négligentes (ou n'ont pas le choix, mais les Pixel offrent ce choix).
De plus, ce n'est qu'un avantage parmi d'autres des Pixel. Ne parlons pas encore de Titan M qui est bien plus avancé que TrustZone et j'en passe (heureusement, ça va évoluer pour les autres constructeurs avec Android Ready SE). Le sujet n'est pas le Google Pixel en particulier, certainement, mais c'est seulement l'un des critères qui en fait le support idéal actuellement, GrapheneOS n'étant pas attaché aux Pixel an particulier.
GrapheneOS ne se contente pas juste d'être une distribution d'AOSP conservatrice du modèle de sécurité d'Android. CalyxOS le fait déjà plus ou moins. GrapheneOS va encore plus loin : protection contre corruptions de la mémoire, pare-feu sans fuites pour chaque application, désactivation possible des capteurs, et j'en passe. Je t'invite à lire mon article qui a été partagé par l'auteur de cette dépêche.
Ces mesures concernent aussi bien la sécurité que la vie privée. Et comme je le répète souvent, la vie privée sans un certain degré de sécurité est illusoire : donc partir d'une baseline Pixel + GrapheneOS comme l'auteur le fait fait pleinement sens, pour ensuite développer ses nouvelles habitudes.
L'inscription aux services Googles ne suffit pas vraiment à déterminer si tu passes ou non par les serveurs Google. Si tu utilises microG, c'est que tu souhaites par exemple bénéficier d'une alternative à FCM (qui permet de délivrer les notifications push pour les apps sans fallback). Il n'y a pas vraiment de magie derrière, microG ne peut pas être considéré simplement comme "les services Google sans Google".
Ce que tu décris à la fin est plus ou moins ce que GrapheneOS compte développer, microG ne satisfaisant pas les critères (et crois-moi, le cas de microG a été longuement étudié). Comme je l'ai écrit, le but sera de faire une implémentation stub minimale qui fera croire aux applications que les services sont présents alors qu'en réalité la connexion aux API Play Services ne sera même pas programmée dans cette implémentation.
Pour résumer, microG nécessite un accès privilégié et d'être build dans l'OS pour fonctionner. C'est entre autres pour ça que microG n'est pas "simplement" une application qui peut être installée sur GrapheneOS pour qui le souhaite : c'est un ensemble privilégié. Donc c'est en réalité beaucoup plus complexe, et ça aurait été un enfer pour GrapheneOS de le supporter et de garantir sa sécurité. Avant qu'on me le dise : oui, GrapheneOS a tenté de travailler avec microG par le passé mais ils n'ont pas été réceptifs.
TL;DR : si tu utilises microG alors que tu ne veux pas utiliser les API Play Services (FCM et consort, soyons d'accord) dont microG implémente un sous-ensemble, il n'y a aucun sens d'avoir ce code privilégié dans ton OS. Il faut des solutions plus minimales, comme ce que GrapheneOS projette de développer. Ou alors, tu peux te passer complètement de tout ça, trouver des alternatives, contacter les développeurs pour faire des fallbacks à FCM. Mais rien n'est sans conséquence, il faut mesurer la portée de chaque chose.
Pour de plus amples discussions à ce sujet avec des développeurs et contributeurs, vous êtes les bienvenus sur les channels Matrix du projet. Je fais de mon mieux pour vous répondre.
microG est mauvaise implémentation des Play Services car nécessite du signature spoofing (moins un problème sur CalyxOS qui whitelist uniquement microG, mais quand même) et n'implémente pas correctement le modèle de sécurité pensé pour les API Play Services (exemple : pas de certificate pinning ou d'autres bonnes pratiques protégeant de MITMs).
microG a encore d'autres problèmes qui leur ont été reportés mais ils ont été peu réceptifs. Par bon sens, il faut donc la considérer comme une surface d'attaque supplémentaire, privilégiée dans l'OS qui plus est, ce qui n'a rien d'anodin (tout comme les Play Services propriétaires, au passage). On ne peut pas promettre de la vie privée sans notion de sécurité derrière pour la soutenir. Sans compter qu'avec microG, tu passes par les serveurs Google, tu envoies des données à Google ; et c'est normal, car c'est une implémentation qui fait exactement cela.
A savoir que GrapheneOS prévoit de développer une implémentation stub justement qui vise à rendre certaines applications compatibles en simulant que les serveurs Play Services sont down. Ce sera une implémentation minimale qui peut être activée et limitée à un user profile.
Enfin, chacun est libre d'utiliser microG, mais il convient de dire les choses clairement et d'éviter de faire une recommandation qui ne convient pas forcément à tout le monde. Il faut faire un choix éclairé : clairement, utiliser microG n'est pas sans conséquences. Et a priori le but de cette dépêche est d'expliquer simplement à tout le monde que oui, utiliser Android (vraiment) sans Google, c'est possible.
Ensuite, chacun mesure les sacrifices qu'il a à faire. Utiliser microG n'est pas une mauvaise chose en soi. Chacun est libre de ses choix, mais la vraie liberté de choix vient avec l'information.
Alors non, ce n'est pas si simple. Le but n'est pas simplement de reverrouiller le bootloader (ce qui est déjà une partie de plaisir), mais d'avoir une implémentation de verified boot fonctionnelle par la suite. Pour ce faire, il doit être possible de pouvoir flasher des clés AVB custom, ce que malheureusement (mais heureusement que ça existe) seuls les Pixels supportent à l'heure actuelle.
Autrement, un bootloader verrouillé seul n'a pas forcément de sens, mais AVB le requiert, et là ça prend tout son sens. (C'est discuté page 2 de ton lien.)
[^] # Re: Intégration sysbox dans runC
Posté par Wonderfall (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 3.
Personnellement je suis un peu sceptique vis-à-vis de sysbox, qui si je ne me trompe pas, repose surtout sur l'utilisation de user namespaces (comme rootless et podman). Le problème des user namespaces c'est que depuis des années on se rend compte que son code (privilégié de surcroît) est problématique et qu'autoriser son accès à des utilisateurs standards est généralement une mauvaise pratique. Et si je ne me trompe pas, avec sysbox, les appels systèmes sont toujours satisfaits par le kernel hôte.
En l'occurrence, Docker Desktop isole l'ensemble des conteneurs dans une VM, mais du coup je doute toujours de l'intérêt de sysbox par rapport à runc + usersn-remap si quelqu'un veut faire la même chose. Je pense que la meilleure approche à terme serait une solution similaire à ce que fait Google avec gVisor (qui fournit un runtime OCI-compliant), qui n'est pas sans défauts mais qui mérite le coup d'oeil.
[^] # Re: Désaccord de principe
Posté par Wonderfall (site web personnel) . En réponse au lien F-Droid: how is it weakening the Android security model ?. Évalué à 3.
Tout à fait, Android a fait un long chemin ! Il devient au fur et à mesure une référence en matière d'OS robuste pour la sécurité et la vie privée, sans sacrifier à l'usage. Et en plus, c'est open-source : peut-être pas "libre" au sens où la communauté de LinuxFr l'entend au sens où il y a peu de place à la contribution communautaire, mais open-source quand même. Je pense que c'est un plus, je le décris même dans mon idéal de la sécurité basée sur l'évidence soutenue par la fameuse Zero Trust Security comme diraient les anglophones.
Quant au Play Store, vous avez le droit de soulever des problématiques à l'encontre de ce service. Le but de cet article n'est pas de glorifier l'usage du Play Store, en fait, je le compare dans certains aspects à F-Droid pour mettre à mal ce dernier. Oui, ça fait mal, c'est normal. Mais ici il n'est pas question de manquer de respect à une éthique ou une culture (libre en l'occurence) quelle qu'elle soit : vous pouvez même voir cet article comme une contribution. Tout est question de perspective. Pour ma part, j'ai choisi de mettre en lumière ces défauts et de contribuer à une alternative qui reprendra depuis le début avec des choix radicalement différents, expliquant que je ne puisse pas contribuer à F-Droid directement. Mais je leur souhaite tout le meilleur, vraiment.
Pour revenir au Play Store, oui, il est loin d'être parfait. Oui, des questions de vie privée ont parfaitement le droit de se poser dès lors qu'un compte est demandé pour accéder à un service essentiel sur Android. Rien de tout cela n'est remis en question, je comprends l'existence de F-Droid. Je mentionne même que je conseille l'utilisation du Play Store sur GrapheneOS car il n'y est pas privilégié, dans le sens où je ne serais moi-même pas forcément à l'aise si je venais à l'utiliser sur un autre OS qui l'intègre dans une sandbox dédiée moins restreinte. GrapheneOS illustre parfaitement que c'est possible, et Google aurait dû le faire comme ça : oui, les services Play (même reproche fait à microG) affaiblissent aussi dans un sens le modèle de sécurité d'Android.
Pour finir, il faut évidemment considérer la sensibilité de chacun : son modèle de menace, sa culture, ses préférences. Mais parfois, certaines analyses froides sont nécessaires, justement pour informer un maximum de personnes, les aider dans ce choix, et contribuer in fine à développer des solutions respectueuses sur tous les plans. C'était simplement mon intention, je comprends qu'elle puisse susciter de vives réactions car j'ai occulté des aspects importants qui méritent vraiment d'autres articles.
[^] # Re: Désaccord de principe
Posté par Wonderfall (site web personnel) . En réponse au lien F-Droid: how is it weakening the Android security model ?. Évalué à 0. Dernière modification le 27 février 2022 à 13:18.
Je vais faire fi de la simplification douteuse que vous faites de ma vision de la sécurité, car non, ça ne se résume pas à une "chaîne de confiance cryptographique". Il ne faut pas tout mélanger, même si effectivement ce journal était déjà la preuve d'un désaccord fondamental.
Vous partez également du postulat que la disponibilité publique du code source est une nécessité pour être audité. C'est simplement faux, ce serait oublier que le code source peut être disponible sur demande, que l'ingénierie inverse existe, et plus particulièrement dans le domaine dans le sécurité des outils comme le fuzzing et les MITM. Avoir le code source c'est bien, mais étudier le code qui est distribué, c'est tout à fait possible. Ce billet résume assez bien ma pensée : https://seirdy.one/2022/02/02/floss-security.html
Il n'y a rien à voir avec une "solution cryptographique" là-dedans, c'est simplement comment les choses fonctionnent dans la vie réelle.
Biaisé par rapport à votre vision de la sécurité informatique, peut-être, mais certainement pas biaisé par rapport à la documentation qui fait état du modèle de sécurité d'Android et des device/user management APIs qui considèrent qu'un store = une source et pas autrement. F-Droid court-circuite fondamentalement cela. Il n'y a rien de compliqué à comprendre, et ça n'a rien à voir avec le débat que j'évoque ci-dessus en soi. Je veux idéalement des solutions FOSS qui ne font pas des compromis qui ne sont pas nécessaires.
Je n'ai jamais demandé à ce que mes articles soient publiés ici, car je sais d'avance que le lectorat libriste a ses propres valeurs qui ne sont pas les miennes. Bien évidemment, je ne peux contrôler comment mes articles sont partagés donc encore une fois, je n'en veux pas aux personnes de mal réagir. Je déplore simplement une perte de temps des deux côtés, et, de mon côté en tout cas, parfois de la stupéfaction et de la déception.
[^] # Re: Désaccord de principe
Posté par Wonderfall (site web personnel) . En réponse au lien F-Droid: how is it weakening the Android security model ?. Évalué à 2. Dernière modification le 27 février 2022 à 03:58.
Nous avons effectivement des référentiels de pensée différents, peut-être opposés (nous ne sommes pas allés dans le détail non plus), et vraiment je n'ai aucun problème avec cela. La diversité d'opinions est une bonne chose. Malgré tout, je ne pense pas que tout peut être relativisé. Il y a des faits dont peut vérifier l'authenticité. Je ne dis pas que mes articles sont dépourvus de biais, car évidemment des biais même inconscients peuvent se glisser dans ma façon d'agir. J'essaie quand même au maximum de promouvoir les analyses objectives, qui sont parfois froides, mais nécessaires. Je vais essayer d'expliquer brièvement ma pensée sur le sujet.
Pour remettre dans le contexte, Android est un système d'exploitation moderne qui se démarque des autres systèmes traditionnels par son application des bonnes pratiques, notamment un écosystème d'applications signées qui sont contenues dans des sandbox très restreintes. Ce dernier permet l'établissement d'un modèle de permissions qui se modernise au fur et à mesure des itérations d'Android. Ce sont les garanties "fortes" dont je parle. Si je souhaite qu'une application n'ait pas accès à mes contacts, elle ne doit pas avoir accès. Si je souhaite qu'elle ait accès à un dossier, je lui donne la permission pour ce dossier seulement.
Je pense effectivement que la disponibilité du code source ne doit pas être une préoccupation majeure dans le cadre d'une approche pragmatique (et pas forcément éthique), tant le code source peut être complexe à comprendre et auditer. De plus, les applications Android sont souvent précompilées en bytecode Dalvik, qui peut toujours se soumettre à l'ingénierie inverse. Le modèle de développement d'un logiciel quel qu'il soit ne doit pas être un feu vert automatique pour savoir que ce dernier fait seulement ce qu'on attend de lui, ou ne contient pas de code vulnérable inconnu du développeur. C'est pour cela que j'insiste sur les garanties fortes permises par des OS modernes. Je vous assure qu'elles sont suffisantes pour l'écrasante majorité des cas, il incombe ensuite à l'utilisateur de décider des permissions à accorder. Les permissions invasives ne sont jamais octroyées par défaut sur de tels OS.
Pour revenir à F-Droid : par leur "contrôle qualité offrant peu de garanties", j'entends que beaucoup de personnes se contentent de F-Droid en tant qu'autorité pour déterminer si une app est sûre ou non. La réalité est que F-Droid n'audite en rien le code source, et lance simplement des scripts pour chercher des trackers connus ; ce qui encore une fois, est une approche que je trouve faible. J'insiste donc sur le fait que F-Droid est une partie intermédiaire qui ne se substitue en rien à la confiance au développeur upstream. Et on ne peut pas leur en vouloir, il n'est pas raisonnable de se lancer dans des audits de code source qui sont humainement laborieux et imprécis.
Je propose donc de placer cette confiance, pour ceux qui souhaitent suivre une approche pragmatique encore une fois, dans le modèle de sécurité robuste de l'OS. C'est évidemment encore mieux sur GrapheneOS qui ajoute un toggle permettant de révoquer la permission INTERNET (coupant cout les tentatives d'exfiltration), et un autre permettant de fournir des données de capteur nullifiées. Mais même Android upstream s'améliore comme dit : cf. les permissions Nearby Devices, et l'ajout à venir d'un sélectionneur granulaire de photo dans MediaProvider, le scoped storage en vigueur depuis le niveau d'API 30. Même s'il y a exfiltration, l'application ne peut avoir accès qu'aux permissions qu'on lui donne à la base, et donc à des types de données précis. Il est tout à fait possible qu'en pratique les applications open-source soient plus enclines à respecter la vie privée. Cependant, je propose tout simplement de ne pas placer cette forme de confiance tout en haut de la hiérarchie, car elle relève de l'appréciation personnelle et du modèle de menace de chacun.
Je n'ai évidement aucun problème avec le logiciel libre et la culture libre dans son ensemble. Il est vrai qu'à titre personnel je ne m'y reconnais plus bien qu'elle ait bercé mon adolescence (je lisais d'ailleurs linuxfr depuis plus de 10 ans), et je lui dois la découverte de nombreux projets. Dans cet article je m'adresse seulement à des faiblesses de F-Droid, et je souhaite réellement voir émerger d'autres alternatives plus en accord avec le modèle de sécurité pensé par et pour Android, qu'elles viennent de GrapheneOS ou d'ailleurs. Les gens sont libres de continuer à utiliser F-Droid, de leur faire confiance, j'expose simplement quelques problèmes dont certains peuvent être réglés par F-Droid pour le bénéfice de tous.
[^] # Re: Désaccord de principe
Posté par Wonderfall (site web personnel) . En réponse au lien F-Droid: how is it weakening the Android security model ?. Évalué à 3. Dernière modification le 26 février 2022 à 23:15.
Auteur ici. J'apprécierais (vraiment) si l'on évite les rapprochements douteux avec des opinions politiques, car si certains pensent que chacun est politisé, les actions ne le sont pas forcément. L'écriture de cet article n'a aucune motivation politique, mais elle suit effectivement une démarche personnelle et n'a pas eu vocation à être partagée massivement.
J'explique justement, parfois en longueur, mon approche pragmatique de la vie privée. Je n'incite pas à se livrer en pâture à Google ou n'importe quelle big tech sans raison. Je demande simplement que l'on regarde objectivement les défauts des solutions FOSS actuelles, ce qu'on peut faire de mieux, et de potentielles alternatives.
C'est faux, et je ne sais pas pourquoi ce mythe est souvent répandu de la même façon pour les paquets des distributions classiques Linux. L'article explique justement que ce principe ne tient pas la route et que vous devez quoiqu'il arrive faire confiance aux développeurs upstreams, et que pour votre vie privée, vous avez davantage intérêt à faire confiance aux garanties offertes par l'OS qu'une vérification très basique du code source (et je suis gentil). C'est juste, à mon sens, du bon sens. Encore une fois, je suis tout à fait compréhensif de la culture libre, mais ce n'est vraiment pas la vision de cet article.
Encore une fois, j'aimerais que les réponses soient plus pertinentes que des "meh biais/sophisme" sans prendre la peine de bien lire les articles et ses références, bien qu'il est évident que nous avons un désaccord de principe (et ce n'est pas la fin du monde, il y a bien pire qui se passe actuellement).
[^] # Re: Relocker le bootloader alias mon téléphone est une brique
Posté par Wonderfall (site web personnel) . En réponse à la dépêche De l'art d'installer GrapheneOS sur son smartphone. Évalué à 1. Dernière modification le 16 juin 2021 à 14:09.
Quoi ? C'est justement le rôle d'Android Verified Boot de prévenir ça.
https://source.android.com/security/verifiedboot
Ensuite pour déverrouiller le bootloader, il faut un accès à l'enclave sécurisée (cf. le post sur le byte OEM unlocking), bonne chance pour le faire sur un Pixel. Ensuite le fait de déverrouiller le bootloader supprime toutes les données, entre autres par une clé de dérivation utilisée en tant qu'input pour le FBE. Ce que tu décris n'est déjà pas possible, mais sera remarqué par l'utilisateur final (et pas qu'un peu !).
Je pense que tu te méprends totalement sur l'intérêt d'un bootloader verrouillé et d'AVB. Merci de ne pas écrire de la désinformation, il y en a déjà beaucoup trop sur la toile… :(
[^] # Re: Relocker le bootloader alias mon téléphone est une brique
Posté par Wonderfall (site web personnel) . En réponse à la dépêche De l'art d'installer GrapheneOS sur son smartphone. Évalué à 2. Dernière modification le 14 juin 2021 à 19:55.
Ce n’est pas tout à fait ça. Sur les Google Pixel par exemple, l’autorisation du déverrouillage est contrôlée par un byte présent sur l’enclave sécurisée, typiquement le TEE (TrustZone) ou un élément sécurisé. Ces enclaves sont particulièrement isolées du reste du système, pour le dire simplement. Les appareils plus négligents stockent ce byte sur une partition, inutile de dire que ça ne protège pas vraiment.
Ce byte est contrôlé par le paramètre OEM unlocking dans les options de développeur sur Android. C’est en fait l’étape finale de l’installation de GrapheneOS ou encore CalyxOS sur Pixel, mais aussi l’étape initiale pour permettre de déverrouiller puis procéder à l’installation de ces images qui sont signées effectivement (mais pas forcément par Google). Pour que Android Verified Boot puisse fonctionner, il faut flasher en effet des clés customs, justement pour cette raison (signées par l’auteur de l’OS en question).
Une fois l’installation finie, on verrouille le bootloader puis on change le byte avec le paramètre OEM unlocking une fois dans Android. Concernant la crainte sur le problème de maj, comme expliqué dans mon article, il y a un système de double partitions au moment de la mise à jour. Au bout de X tentatives ratées, rollback vers la précédente version fonctionnelle.
[^] # Re: Lapin compris
Posté par Wonderfall (site web personnel) . En réponse à la dépêche De l'art d'installer GrapheneOS sur son smartphone. Évalué à 1.
Comme je l’ai dit, le channel Matrix est ouvert à tous. Tu peux poser la question, tu auras la même réponse. Pour les détails, tu peux consulter les logs Freenode (tant que c’est encore possible…).
Je n’ai jamais dit que cette implémentation minimale est magique. Elle pourrait juste aider quelques applications, mais ça ne remplace certainement pas FCM, SafetyNet ou toute la suite d’API Google. Nous sommes d’accord. Il faut tout simplement des fallbacks, des alternatives à ces services prévues par les développeurs ; ou bien des applications qui en font complètement l’impasse.
Dans les faits, pour utiliser des versions d’Android sans Play Services ou apparenté depuis des années, beaucoup d’applications même incompatibles sur le papier fonctionnent. J’en fais part en détails dans mon article dont le lien est dans la dépêche.
[^] # Re: Bootloader
Posté par Wonderfall (site web personnel) . En réponse à la dépêche De l'art d'installer GrapheneOS sur son smartphone. Évalué à 7.
Bonjour, j'ai partiellement répondu à cette question dans certains commentaires. Je me permets de plus ou moins le faire si ça ne dérange pas. :)
Entre autres, un bootloader déverrouillé permet à n'importe quel attaquant physique (on parle de simple "possession" du smartphone) d'exécuter des commandes privilégiées qu'il ne devrait pas pouvoir faire (fastboot et adb). Il permet par exemple d'installer un rookit (un malware persistant), de faire une copie des partitions (les effacer aussi, mais c'est "moins" grave), de pouvoir mener des attaques qui peuvent aller jusqu'à compromettre les données malgré le FDE/FBE (chiffrement de disque/profil). Ce n'est pas alarmiste, ce n'est même pas seulement à la portée d'un attaquant sophistiqué, c'est juste la pierre angulaire du modèle de sécurité mobile.
Android a également cette mitigation que l'on appelle verified boot, c'est la vérification d'intégrité au démarrage du firmware et de l'OS. Elle ne peut pas, par nature, fonctionner avec un bootloader déverrouillé. Elle permet non seulement de lutter contre des attaques physiques mais aussi à distance : les persistances peuvent être détectées, l'idée est de ne jamais démarrer un système compromis et dont il est impossible de retrouver l'état d'intégrité. Le verified boot n'est bien entendu pas propre à GrapheneOS, il est propre à Android mais la plupart des constructeurs en ont une mauvaise implémentation (pour ne pas dire qu'elle ne fonctionne pas). iOS l'a aussi, d'ailleurs.
En d'autres termes, le déverrouillage du bootloader doit être une étape temporaire uniquement lors de l'installation d'un OS custom. L'installateur WebUSB de GrapheneOS l'explique assez bien d'ailleurs, mais n'hésite pas à rechercher pour plus d'informations.
[^] # Re: la contradiction dans l'énoncé
Posté par Wonderfall (site web personnel) . En réponse à la dépêche De l'art d'installer GrapheneOS sur son smartphone. Évalué à 5. Dernière modification le 12 juin 2021 à 14:25.
Il est bon de rappeler que la vérification d'intégrité au démarrage (permise par un bootloader verrouillé) n'est pas "juste" une protection contre les menaces physiques mais aussi une protection générale comme des formes de rootkits quelles qu'elles soient. C'est une mitigation importante pensée dans le modèle de sécurité d'Android, ce n'est pas quelque chose de GrapheneOS, mais c'est quelque chose dont les autres distributions d'Android sont négligentes (ou n'ont pas le choix, mais les Pixel offrent ce choix).
De plus, ce n'est qu'un avantage parmi d'autres des Pixel. Ne parlons pas encore de Titan M qui est bien plus avancé que TrustZone et j'en passe (heureusement, ça va évoluer pour les autres constructeurs avec Android Ready SE). Le sujet n'est pas le Google Pixel en particulier, certainement, mais c'est seulement l'un des critères qui en fait le support idéal actuellement, GrapheneOS n'étant pas attaché aux Pixel an particulier.
GrapheneOS ne se contente pas juste d'être une distribution d'AOSP conservatrice du modèle de sécurité d'Android. CalyxOS le fait déjà plus ou moins. GrapheneOS va encore plus loin : protection contre corruptions de la mémoire, pare-feu sans fuites pour chaque application, désactivation possible des capteurs, et j'en passe. Je t'invite à lire mon article qui a été partagé par l'auteur de cette dépêche.
Ces mesures concernent aussi bien la sécurité que la vie privée. Et comme je le répète souvent, la vie privée sans un certain degré de sécurité est illusoire : donc partir d'une baseline Pixel + GrapheneOS comme l'auteur le fait fait pleinement sens, pour ensuite développer ses nouvelles habitudes.
[^] # Re: Lapin compris
Posté par Wonderfall (site web personnel) . En réponse à la dépêche De l'art d'installer GrapheneOS sur son smartphone. Évalué à 2. Dernière modification le 12 juin 2021 à 02:18.
L'inscription aux services Googles ne suffit pas vraiment à déterminer si tu passes ou non par les serveurs Google. Si tu utilises microG, c'est que tu souhaites par exemple bénéficier d'une alternative à FCM (qui permet de délivrer les notifications push pour les apps sans fallback). Il n'y a pas vraiment de magie derrière, microG ne peut pas être considéré simplement comme "les services Google sans Google".
Ce que tu décris à la fin est plus ou moins ce que GrapheneOS compte développer, microG ne satisfaisant pas les critères (et crois-moi, le cas de microG a été longuement étudié). Comme je l'ai écrit, le but sera de faire une implémentation stub minimale qui fera croire aux applications que les services sont présents alors qu'en réalité la connexion aux API Play Services ne sera même pas programmée dans cette implémentation.
Pour résumer, microG nécessite un accès privilégié et d'être build dans l'OS pour fonctionner. C'est entre autres pour ça que microG n'est pas "simplement" une application qui peut être installée sur GrapheneOS pour qui le souhaite : c'est un ensemble privilégié. Donc c'est en réalité beaucoup plus complexe, et ça aurait été un enfer pour GrapheneOS de le supporter et de garantir sa sécurité. Avant qu'on me le dise : oui, GrapheneOS a tenté de travailler avec microG par le passé mais ils n'ont pas été réceptifs.
TL;DR : si tu utilises microG alors que tu ne veux pas utiliser les API Play Services (FCM et consort, soyons d'accord) dont microG implémente un sous-ensemble, il n'y a aucun sens d'avoir ce code privilégié dans ton OS. Il faut des solutions plus minimales, comme ce que GrapheneOS projette de développer. Ou alors, tu peux te passer complètement de tout ça, trouver des alternatives, contacter les développeurs pour faire des fallbacks à FCM. Mais rien n'est sans conséquence, il faut mesurer la portée de chaque chose.
Pour de plus amples discussions à ce sujet avec des développeurs et contributeurs, vous êtes les bienvenus sur les channels Matrix du projet. Je fais de mon mieux pour vous répondre.
[^] # Re: Lapin compris
Posté par Wonderfall (site web personnel) . En réponse à la dépêche De l'art d'installer GrapheneOS sur son smartphone. Évalué à 9. Dernière modification le 11 juin 2021 à 19:14.
microG est mauvaise implémentation des Play Services car nécessite du signature spoofing (moins un problème sur CalyxOS qui whitelist uniquement microG, mais quand même) et n'implémente pas correctement le modèle de sécurité pensé pour les API Play Services (exemple : pas de certificate pinning ou d'autres bonnes pratiques protégeant de MITMs).
microG a encore d'autres problèmes qui leur ont été reportés mais ils ont été peu réceptifs. Par bon sens, il faut donc la considérer comme une surface d'attaque supplémentaire, privilégiée dans l'OS qui plus est, ce qui n'a rien d'anodin (tout comme les Play Services propriétaires, au passage). On ne peut pas promettre de la vie privée sans notion de sécurité derrière pour la soutenir. Sans compter qu'avec microG, tu passes par les serveurs Google, tu envoies des données à Google ; et c'est normal, car c'est une implémentation qui fait exactement cela.
A savoir que GrapheneOS prévoit de développer une implémentation stub justement qui vise à rendre certaines applications compatibles en simulant que les serveurs Play Services sont down. Ce sera une implémentation minimale qui peut être activée et limitée à un user profile.
Enfin, chacun est libre d'utiliser microG, mais il convient de dire les choses clairement et d'éviter de faire une recommandation qui ne convient pas forcément à tout le monde. Il faut faire un choix éclairé : clairement, utiliser microG n'est pas sans conséquences. Et a priori le but de cette dépêche est d'expliquer simplement à tout le monde que oui, utiliser Android (vraiment) sans Google, c'est possible.
Ensuite, chacun mesure les sacrifices qu'il a à faire. Utiliser microG n'est pas une mauvaise chose en soi. Chacun est libre de ses choix, mais la vraie liberté de choix vient avec l'information.
[^] # Re: Bootloader re-verrouillable
Posté par Wonderfall (site web personnel) . En réponse à la dépêche De l'art d'installer GrapheneOS sur son smartphone. Évalué à 5.
Alors non, ce n'est pas si simple. Le but n'est pas simplement de reverrouiller le bootloader (ce qui est déjà une partie de plaisir), mais d'avoir une implémentation de verified boot fonctionnelle par la suite. Pour ce faire, il doit être possible de pouvoir flasher des clés AVB custom, ce que malheureusement (mais heureusement que ça existe) seuls les Pixels supportent à l'heure actuelle.
Autrement, un bootloader verrouillé seul n'a pas forcément de sens, mais AVB le requiert, et là ça prend tout son sens. (C'est discuté page 2 de ton lien.)