J'utilise une machine Ubuntu Linux. Lorsque j'exécute des applications écrites par différents fournisseurs comme Chrome et Firefox, je remarque qu'elles fonctionnent toutes avec mon uid. Mais si tel est le cas, tout fichier qu'ils créent sur le système de fichiers sera également avec le même uid. Alors, comment sous Linux deux applications non fiables peuvent-elles protéger leurs fichiers l'une de l'autre ?
- l'utilisation d'une règle ACL par l'application A peut toujours permettre à l'application B de lire les fichiers de A, via la partie utilisateur de (utilisateur, groupe, autre)
- les applications doivent-elles utiliser le chiffrement pour protéger leurs données les unes des autres ?
Réponse acceptée :
La réponse littérale est qu'il n'existe pas d'application non fiable exécutée sous votre compte. Si vous souhaitez exécuter une application non approuvée, exécutez-la sous un autre compte ou dans une machine virtuelle.
Les systèmes d'exploitation de bureau typiques tels qu'Unix et Windows et les systèmes d'exploitation mobiles typiques tels qu'Android et iOS ont des modèles de sécurité différents. Unix est un système d'exploitation multi-utilisateurs, avec des utilisateurs mutuellement non fiables. Applications sont considérées comme de confiance :toutes les applications d'un utilisateur s'exécutent dans le même contexte de sécurité. Services , en revanche, sont un peu moins fiables :ils sont généralement exécutés sous un compte dédié, afin de réduire l'impact en cas de faille de sécurité.
Il y a deux raisons principales pour lesquelles le modèle de sécurité Unix fonctionne de cette façon :
- Une raison négative est historique :lors de la conception d'Unix, les applications provenaient d'un petit groupe de programmeurs et étaient soutenues par la réputation du fournisseur ou fournies sous forme de code source ou les deux. Les portes dérobées étaient rarement redoutées dans les applications. De plus, peu d'applications communiquaient sur le réseau, il y avait donc relativement peu d'opportunités de déclencher et d'exploiter des vulnérabilités. Par conséquent, il n'y avait aucune incitation forte à isoler les applications les unes des autres.
- Une raison positive est la fonctionnalité :isoler les applications rend beaucoup de choses impossibles. Si chaque application a sa propre zone de données, cela rend difficile le partage de données entre les applications. Sur un système Unix typique, il est très courant que les mêmes données soient gérées par plusieurs applications. Cela est d'autant plus vrai qu'Unix n'a pas de séparation claire entre les "applications" et "le système d'exploitation". Un navigateur Web est une application. Ne pas pouvoir télécharger un fichier dans le répertoire de son choix, car le navigateur est confiné dans son propre répertoire, est embêtant. Le programme qui affiche les menus et les icônes lorsque vous vous connectez est également une application sur le même pied. Il en va de même pour les gestionnaires de fichiers, qui par définition ont besoin d'accéder à tous vos fichiers. Il en va de même pour les shells et autres interpréteurs qui exécutent des scripts partout. Lorsque vous imprimez un document à partir d'un traitement de texte, cela peut impliquer une application pour convertir le document dans un format imprimable et une autre application pour envoyer les données à l'imprimante.
Bien qu'il y ait beaucoup plus d'auteurs d'applications aujourd'hui qu'il y a 40 ans, les applications sont encore généralement distribuées via des canaux de confiance, qui portent une indication de réputation. (Cela est nettement plus vrai pour Linux que pour Windows, ce qui explique en partie pourquoi les virus sont plus courants sous Windows.) Une application présentant une porte dérobée serait rapidement retirée des référentiels de logiciels Linux.
Connexe :Debian – redimensionner la partition racine sans désinstaller et réinstaller Linux (ou perdre des données) ?Les systèmes d'exploitation mobiles ont été conçus avec différentes menaces à l'esprit. Ils ont été conçus pour des systèmes mono-utilisateur, mais avec des applications provenant de sources totalement non fiables.
L'isolation des applications commence à faire son chemin sur les systèmes Unix de bureau. Certaines distributions exécutent certains programmes sous des cadres de sécurité tels que AppArmor ou SELinux qui limitent ce que l'application peut faire. Le coût de ces restrictions de sécurité est qu'elles rendent parfois impossibles des utilisations souhaitables, par exemple empêcher une application restreinte d'ouvrir des fichiers dans certains répertoires.
Le cryptage serait complètement inutile. Le chiffrement ne protège que les données en transit (sur le réseau) ou au repos (stocké sur un disque), il ne protège pas les données sur un système actif : si le sous-système A déchiffre ses données, il appartient au système d'exploitation d'empêcher le sous-système B d'empêcher l'accès aux données déchiffrées, et donc peu importe si les données ont été déchiffrées par A ou stockées non chiffrées. Le système d'exploitation peut crypter les données, mais uniquement pour les protéger en cas de vol du support de stockage.
Si vous voulez exécuter du code auquel vous ne faites pas confiance, la meilleure chose à faire est de l'exécuter dans une machine virtuelle. Donnez à la machine virtuelle l'accès uniquement aux fichiers dont l'application a besoin (par exemple, ne partagez pas votre répertoire personnel).