-
En même temps, je ne comprends pas trop le problème.
J’ai toujours interdit la connexion root par SSH. Je n’ai quasiment jamais utilisé ou prou sudo, sauf dans un environnement particulier. Je me connecte par SSH à une session, et si j’ai besoin d’administrer le système, je bascule en root, par l’usage de “su -”. Et puis, basta…
Et, quand je dois vraiment utiliser “sudo”, je le configure d’une seule et même manière :
Defaults targetpw
ALL ALL=(ALL) ALL
Qui appelle strictement le compte root… sans avoir la nécessité d’utiliser un utilisateur privilégié.
-
Le fonctionnement de su et sudo sont abordés dans la première partie. L’idée est d’éviter de recourir à des binaires setuid+root qui sont en général une importante surface d’attaque, peu importe s’ils sont configurés pour autoriser ou non certains comptes utilisateurs.
Le gros défaut de “su -” en plus de fonctionner ainsi est de distribuer de façon centralisée le compte root. Vous avez besoin du mot de passe du compte root pour vous y connecter. Avec des clés on évite ce problème.
L’article explique justement qu’interdire la connexion root par SSH est une comédie sécuritaire souvent répandue et fait plus de mal que de bien quand au final on utilise su/sudo.
Je pense aborder un récapitulatif à la fin de l’article pour que ce soit plus clair car peut-être que les informations sont trop dispersées.
-
-
Je dois avouer qu’au départ à première lecture du titre j’ai pas bien vu le rapport du SSH qui remplace sudo. Après en lisant l’article je comprends mieux où tu veux en venir.
-
Oui je m’étais fait la remarque également. :P
-
-
CalyxOS n’adopte plus les mises à jour firmware depuis Octobre (en partie parce qu’ils ont sabordé leur passage à Android 12, et ont viré GrapheneOS de l’AOSP Alliance), et embarque une version de Chromium obsolète impossible à mettre à jour autrement que par l’OS (qui sert la WebView donc utiliser un navigateur tiers ne résout pas entièrement le problème).
Je ne pense pas que ce soit un bon choix compte tenu que GrapheneOS est tout aussi simple d’utilisation (d’autant plus depuis les sandboxed Play services), à jour très rapidement avec l’upstream, avec de vraies améliorations apportées au système plutôt que du marketing basé sur des apps tierces. Je n’avais rien de particulier contre le choix de certains d’utiliser CalyxOS, mais au vu des récents développements et attaques de leur communauté envers les développeurs/contributeurs de GrapheneOS, je serais très méfiant.
Je le dis seulement par principe de réduction de risques, à vrai dire je pense même que l’OS stock des Pixel est préférable à CalyxOS.
-
J’ai eu plusieurs mises à jour depuis octobre, et ils ont sorti des versions beta pour Android 12. Pour Chromium, je ne l’utilise absolument pas, et je l’ai désactivé sur mon Pixel au profit de Mull, mais c’est la version 94 en effet.
-
Mises à jour OS ne veut pas dire firmware. Tu peux voir le “platform” level dans les paramètres (en espérant qu’il ne soit pas artificiellement incrémenté comme LineageOS). Je suis au courant pour les bêta d’Android 12, mais ça ne résout pas le problème : seule la dernière version majeure peut fournir les mises à jour complètes sur un Pixel donné. Ils ont communiqué dessus mais c’est déjà 3 mois de retard alors que des vulnérabilités critiques de Titan M doivent être corrigées.
Chromium 94 devrait toujours servir la WebView car celle-ci est normalement intégrée dans une liste blanche de l’OS. Ce qui pose problème. À voir si CalyxOS contourne cela (ce qui serait inquiétant).
(Encore une fois j’interviens juste pour prévenir, je ne veux pas promouvoir GrapheneOS pour autant même si j’estime qu’ils font bien les choses.)
-
-
-
Wonderfall édité il y a 3 ans | lien | sur : Utiliser un smartphone sans Android et iOS ? « C’est comme apprendre une nouvelle langue »
Je sais pas le plus drôle entre le fait de considérer LineageOS/GrapheneOS comme “pas Android” et le fait de mal orthographier GrapheneOS. Solide comme intro.
AOSP lui-même est libre et open-source… Ce sont les Play services qui ne le sont pas et les surcouches invasives des constructeurs tiers.
L’article est vraiment très peu qualitatif. De plus, “ROM” est un abus de langage, l’OS lui-même n’est pas une ROM. On retrouve des “boot ROMs” à d’autres endroits mais ce n’est pas pertinent d’en parler ici.
De manière générale cet article occulte un nombre important de considérations en matière de vie privée et de sécurité, tout en étant très maigre en informations concrètes et en distillant ce qui sont (à mon humble avis) des mauvaises pistes. C’est très dommage.
-
Merci pour cet article d’excellente qualité ! J’ai découvert l’application magic map grâce à celui-ci !
GrapheneOS a l’air d’être une véritable alternative à LineageOS. Cependant, je me demande par contre comment cela se passe au niveau du financement, qui paye pour tout ce travail ?
-
Bonjour ! Pour le financement, c’est purement des dons. :)
Il se trouve que dans le lot il y a des petits donateurs (comme moi) et des plus gros (certaines entreprises intéressées). Mais il n’y a rien d’autre, le projet ne vend rien en soit et n’exige aucune contrepartie si quelqu’un venait à vendre des smartphones sous GrapheneOS.
Il y a heureusement suffisamment de donations pour que le développeur principal puisse en vivre, payer toute l’infrastructure et rémunérer d’autres développeurs. C’était un peu plus compliqué avant à cause d’une bataille judiciaire liée à CopperheadOS, mais je ne voulais pas trop en parler car je ne voulais pas leur donner plus de visibilité que ça. Heureusement, c’est presque terminé et tout se finit bien.
-
-
Hum c’est marrant cette définition de la sécurité, considérer GooglePlay secure …
-
Bonjour,
Pardon ? J’écris exactement le contraire pourtant. Les Google Play Services doivent être évités si possible, ils constituent une surface d’attaque importante et une portée d’entrée vers des nuisances à la vie privée. microG est à éviter aussi, car bien qu’open source, nuit au modèle de sécurité Android (signature spoofing) et Google Play (certificate pinning). Je ne peux pas faire plus simple.
Et oui, je considère qu’un Android stock sur Pixel (AOSP avec peu de modifications + Play Services à jour qu’on peut bien configurer) bien plus sûr et respectueux qu’une vieille version d’Android sur un Xiaomi qui combine les Play Services avec des tonnes de services tiers (pour ne citer qu’eux).
Comme je l’ai expliqué à la fin, si les GAFAM font l’objet principal de votre modèle de sécurité, GrapheneOS qui est une expérience AOSP sans concessions sur la sécurité et 100% sans Google, est probablement fait pour vous (comme il l’est pour moi). :)
-
Bonjour,
Et bah pardon alors, mais j avais l impression de lire que les plays service etait plus sure que microg … Effectivement le signature spoofing, c’est pas glorieux, mais toujours mieux que le ce truc closed source.
Mais oui GrapheneOS est probablement la meilleur alternative sécurisé sans les play service. Et paradoxalement seulement disponible sur Pixel
-
-
-
Chouette article !
Par contre on peut avoir l’intéret d’avoir un VPN pour autre chose que l’anonymat.
- On peut vouloir un VPN pour se garantir un accès neutre à l’Internet et en outrepassant les éventuelles contraintes de son FAI.
- pour avoir une IP fixe pour héberger des serveurs.
- avoir de l’IPv6 quand son FAI n’en propose pas.
- Ou bien avoir une IPv4 non déclarée comme résidentielle afin d’héberger du mail chez soit sans se faire blacklist instantannément.
Et surement d’autres cas d’usage.
-
Salut, merci du retour ! Oui c’est ce que j’essaie de dire, et je termine même l’article sur cette note. Il y a des cas valables dans le monde utilitaire et professionnel, c’est l’utilité historique même.
Pour le premier point c’est que je voulais sous-entendre quand je parle du DPI, mais c’est exactement ça. Le reste sont des cas entièrement valables évidemment.
-
Bonsoir, article bien écrit, bien mené.
Mais tu confirmes ce proverbe : “la sécurité est un leurre..”
“qui ne profites qu’aux riches !”
(et encore)
Bref, même en étant conscient des nécessités, tout le monde ne peut s’offrir ce luxe. Loin s’en faut. Et, même en étant conscient de cette nécessité, elle s’arrête où, au détriment des usages !?
-
Bonsoir,
Effectivement, c’est un portrait un peu triste qu’on peut dresser du paysage de la sécurité mobile. Des initiatives louables visant à lutter contre l’obsolescence programmée ont des limites, car si les constructeurs ne fournissent plus des patchs de sécurité, on a beau patcher le reste, on ne peut pas tout faire, c’est pas raisonnable. Donc il faudrait idéalement changer son smartphone dès qu’il n’est plus officiellement supporté (malgré le support par des customs ROMs), mais ça c’est pas évident pour tout le monde.
Aussi c’est important de faire un modèle de sécurité, même si je suis convaincu qu’un Pixel 3a est par exemple assez accessible (on a eu des promos en-dessous de 250 récemment), et le 4a sera un très bon MDG à 350€ neuf. L’iPhone SE est également une bonne nouvelle, même si on se fait douiller comme d’habitude en Europe niveau prix.
Je pense que la réflexion peut se poser, ce serait bien de voir d’autres constructeurs prendre la problématique au sérieux. GrapheneOS a toujours eu pour projet de proposer son propre hardware accessible, mais ça, ce n’est qu’à l’étape du rêve encore…
La sécurité doit être à portée de tous, et on ne devrait pas faire tant de concessions pour l’avoir.
-
Je pense qu’on est loin des mêmes réalités financières. Mettre 3-400 roros, dans un portable, ce n’est pas à ma portée, et je ne fais pas partie de la catégorie “famille pauvre”. Et, quand bien même, je ne vois pas l’intérêt de mettre tant d’argent dans cet appeau. Je sais que d’aucuns sont prêts à bien des sacrifices financiers pour paraître “riche”, en ayant le dernier smartphone de chez A*, de chez G* ou de chez S*, voire X*…
Bien que la démarche de ce monsieur d’apporter de la sécurité, en soit est intéressante, il en est que si elle ne doit être accessible au doux sacrifice pécuniaire qui te coûte un bras, un rein, voire de manger, pour certains cas, à quoi bon ?!
C’est un tracas de riche, cette soit-disante sécurité. Il y a derrière un relent, qui me déplaît personnellement. C’est pareil qu’à une dictature ou l’autre, d’aucuns estiment très sérieusement que c’est le seul moyen de garantir, tout aussi, sérieusement la sécurité. Alors, certes, on n’est pas sur le même niveau d’échelle, et, je le comprends très bien. Mais si pour avoir la sécurité en question, je ne l’aie qu’au-travers d’un dictat-phone, en quoi, c’est mieux, dans le fond ?!
J’apprécie vraiment ta dernière phrase ;-)
C’est un peu comme utiliser OpenBSD, que j’utilise au quotidien, le “vantard de la sécurité informatique” - entendons-nous bien, je l’utilise au quotidien - mais à moment donné, la sécurité empiète très fortement sur l’usage. Cela est un autre aspect, et parfois, m’agace tout autant.
Ce qui m’est clair est que le béotien/nouveau/quidam/Monsieur X/Madame Michu n’est pas prêt du tout à cette contrainte de la sécurité.
Non seulement, la sécurité en question ne devrait pas être contrainte à la concession, mais elle ne devrait pas plus être contrainte à la contrainte de l’usage. En fait, comme l’informatique, elle devrait se rendre invisible, tout en étant prégnante. Là, elle serait utile réellement à tous.
Je m’égare certainement. En tout cas, merci pour ta réponse que j’apprécie. ++
-
-
Désolé mais je ne suis pas convaincu :/ Je ne vois pas ce que cela apporte de se connecter au compte root via ssh plutôt que sudo si ce n’est de la lourdeur.
Un des intérêt d’utiliser sudo est de ne pas communiquer le mot de passe root et d’éviter que celui-ci soit perdu ou qu’il doive être modifier en plus de permettre de faire un suivi des opérations utilisées via sudo. Je ne me connecte jamais en root sauf lorsque sudo ne fonctionne pas et uniquement pour l’opération concernée.
Il est indiqué dans le titre, partie 2, mais je trouve pas la partie 1.
La première partie est le premier article qui est en lien dans l’article. Elle expliquera justement en quoi sudo est davantage une lourdeur plutôt que simplement utiliser SSH.
Il me semble avoir abordé tous ces points, notamment :
Le but de l’article est surtout de faire comprendre que la connexion à root via SSH n’a rien de problématique d’autant plus quand la pratique d’utiliser des binaires setuid+root avec un historique d’exploitation est déjà répandue. Mais aussi qu’il y a, de toute façon, des problèmes bien plus sérieux suivant le modèle de sécurité abordé.
Cependant je pense modifier l’article pour préciser que l’article du début est la première partie, et aussi ajouter une meilleure comparaison entre su/sudo/SSH pour l’utilisation de root.
Merci pour les précisions !
J’ai apporté des modifications en espérant que ce soit plus clair comme ça !