Pourquoi les applications mobiles ont-elles des autorisations précises alors que les applications de bureau n'en ont pas?
Les applications Androids utilisent des autorisations précises pour des raisons de sécurité, les applications iOS (afaik) le font également. Les applications Windows 8.1 n'ont pas de schéma d'autorisation comme ça, toutes les versions de Linux que j'ai essayées jusqu'à présent ne l'ont pas non plus et je suppose que Mac OS X ne l'a pas non plus, non?
Pourquoi ces autorisations détaillées sont-elles considérées comme nécessaires sur un appareil mobile, mais pas sur un système de bureau? Les utilisateurs font-ils moins confiance aux applications sur un appareil mobile que sur un système de bureau?
Est-ce que Windows 10 ou les versions plus récentes de Linux et Mac OS en auront?
PS: il semble que certaines personnes considèrent qu'il s'agit d'un doublon possible Pourquoi les applications pour les appareils mobiles sont-elles plus restrictives que pour les ordinateurs de bureau? - mais les deux questions diffèrent au moins du point de vue (développeur/utilisateur ). Et si vous lisez la réponse, vous verrez également que la plupart des utilisateurs SO considèrent les deux questions comme étant différentes :-)
Il y a deux raisons principales pour lesquelles les smartphones ont des autorisations précises, contrairement aux ordinateurs de bureau.
Histoire. Les systèmes d'exploitation mainframe ont pour tradition d'accorder des autorisations au tilisateur plutôt qu'au programme, et cela se répercute sur les mini-ordinateurs/postes de travail/ordinateurs de bureau; le désir de maintenir la compatibilité avec les programmes existants limite la capacité de changer les choses. Les smartphones constituent une rupture nette avec les écosystèmes d'applications existants, il était donc possible de modifier le modèle d'autorisations.
Les smartphones sont beaucoup plus homogènes que les ordinateurs de bureau et ne changent généralement pas leur configuration matérielle au fil du temps. Cela facilite la configuration du système d'autorisations.
Cela dit, il existe des systèmes d'autorisation à granularité fine pour les systèmes d'exploitation de bureau. Linux, par exemple, a AppArmor, SELinux, Bitfrost et probablement d'autres.
Pour des raisons techniques, il n'est pas possible de dire de quelles autorisations une application a besoin jusqu'à ce qu'elle essaie de les utiliser, ce qui signifie qu'une application a besoin d'un moyen pour le déclarer. Les applications sur les systèmes d'exploitation de bureau n'ont jamais fait cela. Lorsque l'utilisateur démarre une application héritée, vous pouvez seulement supposer qu'il a besoin de tout (former l'utilisateur à accepter de longues listes de capacités sans y penser) ou demander avec une fenêtre contextuelle le moment où l'application en a besoin (ce qui pourrait casser certaines applications qui peuvent '' t faire face à l’interruption soudaine). Les deux solutions sont mauvaises, donc l'introduction d'un tel mécanisme romprait la rétrocompatibilité avec les logiciels plus anciens.
Windows 7 a en quelque sorte essayé d'améliorer la situation en autorisant les applications plus récentes à déclarer qu'elles ne feraient pas certaines choses potentiellement malveillantes et à ajouter l'invite "Voulez-vous que [programme] apporte des modifications à votre ordinateur" lors du démarrage d'un ancien programme qui ne fonctionne pas ' t ainsi que d'empêcher certaines choses encore plus malveillantes à moins que le programme ne soit exécuté en tant qu'administrateur.
Les systèmes d'exploitation UNIX et UNIXoid comme Linux permettent de restreindre les droits des programmes avec leur système d'autorisation et de propriété de fichiers. Les périphériques matériels sont également extraits sous forme de fichiers et peuvent appartenir à un certain groupe. Vous pouvez donc restreindre les capacités des programmes en exécutant chaque programme avec un utilisateur différent et en ajoutant l'utilisateur aux groupes qui possèdent les "fichiers" de périphérique matériel requis par le programme. Ce n'est bien sûr pas une solution très conviviale car elle nécessite beaucoup de configuration.
Lorsque les systèmes d'exploitation pour smartphones ont été développés, il n'y avait pas d'applications héritées pour lesquelles les développeurs devaient garantir la compatibilité, ils ont donc la chance de tout faire dès le départ.
Une autre raison est que les smartphones peuvent être bien plus susceptibles de porter atteinte à la vie privée que les ordinateurs de bureau. Un smartphone dispose d'un capteur GPS, d'un microphone, d'une caméra et d'une connexion Internet permanente et la plupart des utilisateurs effectuent la plupart de leurs communications privées et professionnelles par leur intermédiaire. Tout cela ne serait pas si mal quand les gens n'auraient pas ces appareils sur ou près de leur personne à tout moment où qu'ils aillent. Les smartphones sont tout simplement les outils d'espionnage parfaits. Lorsque vous maîtrisez un smartphone, vous bénéficiez d'une parfaite surveillance 24/7 de l'utilisateur et de son environnement. Et tout ce que vous auriez besoin de faire pour avoir accès à cet outil est d'inciter l'utilisateur à installer votre application de son fart.
Il existe au moins deux raisons importantes pour lesquelles les systèmes d'exploitation mobiles ont des autorisations précises pour les applications, alors que les systèmes d'exploitation de bureau ne le font pas:
Historique. Les systèmes d'exploitation de bureau remontent à plusieurs décennies, lorsque le modèle de menace principal était différent, et ont par conséquent des mécanismes conçus pour y faire face (maintenant largement) obsolète) modèle de menace.
Les systèmes d'exploitation de bureau sont une évolution des systèmes d'exploitation mainframe. Sur les mainframes, la principale préoccupation était la sécurité multi-utilisateurs: le système d'exploitation devait garantir qu'un utilisateur ne pouvait pas attaquer un autre utilisateur. Ainsi, les systèmes d'exploitation de bureau sont généralement construits autour d'un modèle de sécurité multi-utilisateurs, qui essaie d'isoler les utilisateurs les uns des autres et de garantir qu'un utilisateur ne peut pas attaquer d'autres utilisateurs sur la même machine.
Cependant, aujourd'hui, la plupart des machines sont des machines mono-utilisateur, et la principale menace n'est pas les autres utilisateurs mais plutôt les attaques malveillantes d'autres sites ou données sur Internet. Ainsi, les systèmes d'exploitation mobiles sont conçus pour répondre à ce modèle de menace moderne. Ils sont conçus pour faciliter et sécuriser le téléchargement et l'exécution d'une application créée par un développeur non fiable; les mécanismes existants (bacs à sable des applications, systèmes d'autorisation, magasins d'applications, avis sur les applications) contribuent à rendre cela généralement assez sûr. Ainsi, les systèmes d'exploitation mobiles se concentrent sur la protection contre les applications malveillantes/fragmentaires et isolent les applications les unes des autres, plutôt que d'isoler les utilisateurs les uns des autres.
Cela explique en grande partie pourquoi les systèmes d'exploitation mobiles ont des autorisations précises tandis que les systèmes d'exploitation de bureau n'en ont pas: les autorisations précises sont plus utiles pour gérer le modèle de menace moderne (protéger les utilisateurs contre les applications malveillantes/louches) que l'ancien ordinateur central. modèle de menace (protéger les utilisateurs les uns des autres).
Si nous devions concevoir des systèmes d'exploitation de bureau à partir de zéro aujourd'hui, il est plausible qu'ils ressemblent beaucoup plus à des systèmes d'exploitation mobiles modernes, en mettant l'accent sur un modèle d'application, un modèle de menace d'application au lieu d'un modèle de menace multi-utilisateurs, etc. . Cependant, en raison des contraintes héritées, il n'est pas facile pour les systèmes d'exploitation de bureau de passer à cette nouvelle approche: les utilisateurs s'attendent à ce que les applications de bureau existantes fonctionnent, de sorte que les systèmes d'exploitation ne peuvent pas simplement les bloquer. En revanche, lorsque Apple et Google ont introduit iOS et Android, il s'agissait de nouveaux systèmes d'exploitation sans base héritée; il n'y avait aucune application existante avec laquelle ils devaient être compatibles, afin qu'ils puissent changer la modèle de programmation d'une manière fondamentale que les OS de bureau ne peuvent pas facilement faire.
Différentes bases d'utilisateurs, différents compromis, différentes menaces. Les smartphones sont un appareil grand public. Ils doivent travailler pour tout le monde. Sur un bureau, l'installation d'une application sommaire peut laisser votre bureau mal fonctionner, laisser votre bureau encombré de logiciels espions et rendre le système lent ou instable. Sur les ordinateurs de bureau, si vous ne savez pas ce que vous faites, vous pouvez vraiment bousiller la fiabilité et les performances de votre ordinateur. Il serait inacceptable que votre téléphone fonctionne comme ça - donc Apple et Google ont travaillé dur pour concevoir un système d'exploitation afin de garantir que l'installation d'une mauvaise application ne puisse pas faire cela. Cela impose différents compromis et différents objectifs de conception, et conduit naturellement à une plate-forme plus verrouillée et permet certaines conceptions qui pourraient être considérées comme acceptables sur un ordinateur de bureau.
En outre, les smartphones disposent d'une grande variété de capteurs qui peuvent capturer une grande partie de votre vie (par exemple, enregistrer des conversations, suivre votre emplacement, etc.), et votre téléphone est avec vous tout au long de la journée, il y a donc sans doute plus de possibilités de mauvaise confidentialité violations. C'est une autre motivation pour un modèle de sécurité plus fort.
Cela dit, les systèmes d'exploitation de bureau modernes le sont commencent à adopter lentement certaines de ces idées à partir de systèmes d'exploitation mobiles centrés sur les applications. Par exemple:
Mac OS X prend en charge les applications en bac à sable, ce qui fait que les applications ressemblent beaucoup plus à une application mobile. Les applications sur le Mac App Store sont généralement en bac à sable . Le système d'exploitation fournit un modèle d'autorisation à granularité fine, et l'application doit déclarer les autorisations (autorisations) dont elle a besoin.
Windows 8 prend en charge les applications en bac à sable, avec un modèle de sécurité qui ressemble beaucoup à celui d'une application mobile. En particulier, applications Windows Store s'exécutent dans un bac à sable et doivent déclarer les autorisations dont ils ont besoin. Les utilisateurs peuvent voir les autorisations dont dispose une application .
Soit dit en passant, vous remarquerez peut-être que le modèle de sécurité des applications mobiles ressemble vaguement au modèle de sécurité du Web: le Web est également basé sur l'isolement des sites les uns des autres, de sorte qu'un site Web malveillant ne peut pas attaquer un autre site. Si vous considérez une application mobile comme analogue à un site Web, le sandboxing des applications mobiles ressemble maintenant aux politiques de même origine du navigateur. Historiquement, les applications Web étaient beaucoup plus limitées dans ce qu'elles pouvaient faire, mais avec HTML5, cela change. Les navigateurs commencent à permettre aux services Web d'avoir des pouvoirs plus étendus (lire à partir de capteurs, lire et écrire des fichiers sur votre système de fichiers, etc.) et commencent à mettre en œuvre des systèmes d'autorisation pour contrôler l'accès à ces ressources, tout comme les systèmes d'exploitation mobiles. Ainsi, vous pouvez voir cela comme des navigateurs empruntant certaines idées aux systèmes d'exploitation mobiles.
Quelques autres lectures qui pourraient vous intéresser:
Voir Alternatives au modèle de sécurité "PC ouvert" pour d'autres modèles de sécurité, au-delà du modèle d'application et du modèle "PC ouvert".
Voir Politique de même origine pour les applications de bureau? pour une discussion sur le modèle de système d'exploitation de bureau et certains cas où des autorisations plus fines ont été greffées sur des systèmes d'exploitation de bureau standard.
À titre de comparaison, jetez un œil aux options de pare-feu sur un smartphone par rapport à un système d'exploitation de bureau - je pense que vous constaterez que le bureau a des options de pare-feu beaucoup plus fines (à l'exception des applications de pare-feu racine sur Android), vous permettant de spécifier quel exécutable a accès aux communications sur quels ports et sur quels réseaux, alors qu'il est presque impossible de bloquer l'accès à Internet à une application téléphonique (car ils veulent tous des publicités via Internet pour gagner de l'argent, semble-t-il)
Regardez la coupure d'une application - est-il facile de couper une seule application dans windows vs sur un appareil mobile - pouvez-vous spécifiquement couper tous les sons? facile à faire dans les deux - mais qu'en est-il du programme/de l'application X? ou pouvez-vous régler le volume du programme Y de sorte qu'il soit la moitié de celui du programme X? Je dirais que le bureau a un accès plus fin ici
Les PC ont également des options de surveillance plus avancées - vous pouvez aller voir exactement quel processus accède à quels fichiers à un moment donné, regarder les threads individuels pour chaque processus, les exécuter via un anti-virus (en bac à sable?), Qui, bien que techniquement possible sur un téléphone mobile est beaucoup moins pratique, et les AV basés sur le téléphone ne sont pas aussi bons que leurs homologues de bureau.
Je pense que la raison générale est qu'un téléphone n'est pas vraiment "le vôtre" jusqu'à ce que vous le rootiez/obteniez un accès administrateur, alors que sur un PC, c'est la norme - en tant que tel, les téléphones veulent compenser en vous faisant "sentir" habilité, même si vous ne l'êtes vraiment pas, alors que le PC peut vous offrir pratiquement tout ce que vous voulez si vous le configurez simplement comme tel (exécutez des applications non fiables dans une machine virtuelle, bac à sable, etc.)
Il semble également y avoir des différences d'utilisation: sur un téléphone, presque toutes les applications souhaitent accéder à vos contacts, votre position, etc. - sur un PC, très peu (le cas échéant) demanderont de "synchroniser" les contacts entre différentes applications, ou même des signets - il s'agit généralement de "migrer les paramètres" en une seule fois - les applications sont toutes très autonomes, contrairement à chaque application qui dépend fortement du système et d'autres applications pour faire des choses à leur place (combien d'applications fonctionnent dans Android sans les services Google Play? Qu'en est-il sur Windows sans le service X en cours d'exécution)? Regardez les lecteurs multimédias - la plupart des lecteurs multimédias de bureau sont autonomes car ils ont leurs propres codecs, alors qu'il est pratiquement impossible pour trouver un lecteur multimédia qui a ses propres codecs et ne s'appuie pas sur les codecs du système (et donc hérite de ses défauts) sur mobile.
Ce n'est en fait que Windows qui n'a pas cela. (Sauf les applications appstore). Sous OS X, vous devez donner l'autorisation avant d'accéder à des éléments tels que les contacts ou si une application souhaite apporter des modifications au système de fichiers en dehors du conteneur de l'utilisateur.
Pour Linux, il existe des choses comme AppArmor et SELinux, mais sur la plupart des unités, bsd est un linux le modèle d'autorisation de système de fichiers normal rend de toute façon impossible pour les programmes utilisateur normaux d'apporter des modifications en dehors du domicile de l'utilisateur.
Bien que Windows ait maintenant l'UAC, il est assez inutile car presque toutes les applications ont besoin d'un accès complet au système de fichiers pour fonctionner. (Sauf les applications de consommation multimédia)
Les applications de bureau devraient faire bien plus que les applications mobiles, il est donc beaucoup plus difficile de leur accorder des autorisations précises. En particulier, les applications de bureau communiquent souvent entre elles, tandis que les applications mobiles sont généralement très très très en bac à sable pour éviter une telle communication. Si vous autorisez la communication inter-applications, les privilèges affinés disponibles sont ceux de l'application, plus tout ce qu'elle peut convaincre d'autres applications de faire pour elle (y compris l'utilisation d'exploits pour le faire convaincant). Avec les bons exploits, ces privilèges peuvent être pratiquement sans rapport avec les privilèges pour lesquels l'utilisateur a cliqué sur OK.
Dans cet environnement, les privilèges à grain fin n'offrent pas autant que nous le souhaiterions, et ils sont coûteux à intégrer dans un système. Par conséquent, les OS de bureau le prennent rarement en charge.