Lorsque j'installe un programme comme GIMP ou LibreOffice sur Linux, on ne me demande jamais les autorisations. En installant un programme sur Ubuntu, est-ce que je donne explicitement à ce programme la permission complète de lire / écrire n'importe où sur mon disque et un accès complet à Internet?
Théoriquement, GIMP pourrait-il lire ou supprimer n'importe quel répertoire sur mon lecteur, ne nécessitant pas de mot de passe de type sudo?
Je ne suis curieux que si c'est techniquement possible, pas si c'est probable ou non. Bien sûr, je sais que ce n'est pas probable.
permissions
security
software-installation
stackinator
la source
la source
Réponses:
Il y a deux choses ici:
lorsque vous installez un programme par des moyens standard (programme d'installation du système tel que apt / apt-get sur Ubuntu), il est généralement installé dans un répertoire où il est disponible pour tous les utilisateurs (/ usr / bin ...). Ce répertoire nécessite l'écriture de privilèges, vous avez donc besoin de privilèges spéciaux lors de l'installation.
lorsque vous utilisez le programme, il s'exécute avec votre identifiant utilisateur et ne peut lire ou écrire que là où les programmes exécutés avec votre identifiant sont autorisés à lire ou à écrire. Dans le cas de Gimp, vous découvrirez par exemple que vous ne pouvez pas éditer des ressources standard telles que des pinceaux car elles sont dans le partage
/usr/share/gimp/
et que vous devez d'abord les copier. Cela montre égalementEdit>Preferences>Folders
où la plupart des dossiers se présentent par paires, un système qui est en lecture seule et un utilisateur qui peut être écrit.la source
rm -rf ~/
. Si vous installez à partir d'autres sources, vous devez être prudent (ou installer à partir des sources, après une inspection du code).Oui, si vous utilisez
sudo
ou l'équivalent, vous donnez au programme d' installation la permission complète de lire / écrire n'importe où sur votre disque. C'est à peu près la même chose. Il existe également un indicateur que l'installateur peut définir, appelé setuid, qui donnera au programme des autorisations complètes après l'installation également.Même si nous ignorons le programme d'installation et si le programme n'est pas setuid (il est très rare que les programmes utilisent setuid), lorsque vous exécutez le programme, il a un accès complet à tout ce à quoi votre compte peut accéder. Par exemple, si vous êtes connecté à votre banque en ligne, cela pourrait hypothétiquement envoyer tous vos fonds au Nigéria.
Le modèle de sécurité - c'est-à-dire la façon dont le système de sécurité est conçu - sous Linux est très ancien. Il est hérité d'Unix, qui remonte aux années 1960. À l'époque, il n'y avait pas d'Internet et la plupart des gens d'un service utilisaient le même ordinateur. La plupart de vos programmes provenaient de grandes entreprises de confiance. Le système de sécurité a donc été conçu pour protéger les utilisateurs les uns des autres, et non pour protéger les utilisateurs des programmes qu'ils exécutent.
De nos jours, il est assez dépassé. Android est basé sur Linux, mais il fonctionne en créant un "compte d'utilisateur" distinct pour chaque application, au lieu de pour chaque utilisateur. Je ne sais pas ce qu'iOS utilise. Des efforts comme Flatpak tentent actuellement d'apporter le même genre de chose au bureau Linux.
la source
Ce que vous voulez est fourni par les applications Flatpack. Ce sont à peu près l'équivalent des applications iOS, Android ou Windows Store.
Je ne les ai pas utilisés, donc je ne sais pas s'ils ont déjà implémenté l'interface graphique, pour voir les autorisations requises par chaque application lors de son installation.
https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-security-model-part-2-who-needs-sandboxing-anyway/
Je n'ai pas non plus utilisé l'alternative d'Ubuntu, Snappy, pour savoir si elle fournit une telle fonctionnalité visible dans l'interface graphique.
la source
C'est techniquement possible et les solutions incluent
apparmor
,selinux
etfirejail
même des conteneurs complets commeLXC
ou une machine virtuelle complète (par exempleVirtualBox
,kvm
ouvmware
). Pour la mise en réseau, il existeopensnitch
un clone dulittlesnitch
programme OSX.La raison pour laquelle il n'y a pas de modèle de sécurité répandu avec des autorisations accordées par l'utilisateur est que, traditionnellement, vous faites attention à ce que vous exécutez sur votre PC. 90% de ce qui se trouve dans les appstores des systèmes mobiles serait considéré comme un malware sur PC.
Il existe des scanners pour les logiciels publicitaires (c'est-à-dire adaware ou Spybot D&D) qui classeraient les comportements tels que la connexion de Facebook, Google Analytics et les réseaux publicitaires comme des logiciels malveillants sur le PC. L'écosystème mobile est comme un redémarrage complet de l'informatique en ce qui concerne ces choses. Tout le monde regroupe les logiciels publicitaires, juste parce que c'est facile et ajoute des analyses, juste parce qu'il est curieux. Les effets secondaires sont une diminution de la confidentialité et de la sécurité. La partie sécurité est prise en compte par le modèle sandbox, la partie confidentialité est toujours un problème ouvert.
Une autre raison de ne pas avoir cela sur le PC pendant longtemps est la complexité d'un bac à sable, ce qui signifie qu'il peut être trop lent pour les anciens PC il y a quelque temps et nécessiter plus d'ingénierie pour quelque chose qui n'avait alors que peu d'avantages.
Aujourd'hui, nous voyons des tentatives d'utilisation du sandboxing dans de nouveaux formats de package comme snap et flatpak et les navigateurs l'utilisent également pour leurs extensions. Chromium utilise un modèle d'autorisation depuis le début et Firefox en utilise un pour toutes les extensions Web (depuis 57 les seules extensions que vous pouvez installer). Cela est tout à fait raisonnable, car les gens installent des extensions de navigateur d'auteurs inconnus tout comme les applications de personnes dont ils n'ont jamais entendu parler, pensant qu'ils ne sont pas plus dangereux qu'un site Web qu'ils visitent, ce qui est une erreur fausse lorsqu'il n'y a pas de bac à sable pour les protéger.
la source
Android utilise un modèle de sécurité «marketplace»: différentes applications proviennent de différents fournisseurs (semi-fiables) et doivent être isolées des ressources protégées et les unes des autres. La plupart des applications sont distribuées à but lucratif: elles sont vendues (payantes), diffusent des publicités payantes ou «monétisent» leurs utilisateurs en vendant leurs données à des tiers. Il y a une forte motivation à s'engager dans un accès illicite aux données, même s'ils se font prendre.
La plupart des applications dans Debian, Red Hat et les distributions Linux "classiques" similaires sont distribuées sous forme source: après qu'une application open source gagne suffisamment de traction, elle est choisie manuellement pour être incluse par les responsables de la distribution. Il y a peu de motivation pour effectuer un accès illicite aux données, - les gains potentiels ne justifient pas les efforts.
Il convient de noter que ce modèle de sécurité avancé d'Android est l'une des raisons pour lesquelles il a gagné en popularité, surmontant facilement iOS sur les marchés mobiles. Les distributions Linux de bureau modernes ne sont pas seulement «différentes», elles sont en fait bien en retard en termes de modèles de sécurité et de distribution.
Certaines distributions Linux proposent des améliorations à leur système de distribution de logiciels: référentiels de logiciels tiers centralisés (AUR), formats de packages spécialisés pour la distribution de logiciels tiers (AppImage, Snappy, Flatpack), systèmes de référentiels secondaires (Docker). Malheureusement, ces améliorations gagnent très peu de terrain avec le temps: AppImage a été inventé en 2004, la première version d'AUR est sortie en 2005, mais aucune des distributions Linux modernes n'a officiellement adopté ses fonctionnalités après> 10 ans.
la source
Ces applications sont installées dans une partie privilégiée du système de fichiers que vous et la plupart des utilisateurs n'avez normalement pas accès pour modifier.
Sur les distributions principales configurées pour une utilisation sur ordinateur, l'utilisateur unique initialement configuré lors de l'installation aura généralement des droits d'administrateur. Tout ce qui leur sera normalement demandé, c'est leur propre mot de passe de connexion pour installer le logiciel, et pas toujours.
Une fois installé, le logiciel sera, par défaut, configuré pour être exécutable par les utilisateurs normaux et permettre la lecture des fichiers de données. C'est tout ce qu'il faut.
Pas le programme. Ce qui se passe, c'est que le compte d'utilisateur appartient à différents groupes et que les différents groupes accordent l'accès à différentes ressources.
Le modèle de sécurité sous Linux est que votre compte d'utilisateur dispose de certains droits et que les groupes auxquels votre compte appartient ont des droits spécifiques. Pour accéder à n'importe quelle partie du système de fichiers, il faut des privilèges root, qui ne sont normalement pas accordés aux utilisateurs. Même lorsque vous utilisez sudo, vous n'obtenez pas tous les droits.
Les comptes d'utilisateurs normaux ont généralement accès aux ressources dont ils sont censés avoir besoin, comme Internet.
Tout répertoire ou fichier auquel vous, en tant qu'utilisateur, avez des droits d'accès est accessible par l'application que vous lancez car il hérite généralement de vos droits. Un utilisateur normalement connecté n'aura pas par défaut le droit de modifier la plupart des fichiers système critiques ou des fichiers partagés.
Gardez à l'esprit que la plupart des utilisateurs installent généralement des applications à partir de référentiels bien contrôlés et que le risque de code hostile est faible.
Je suggérerais probablement quelques lectures supplémentaires pour maîtriser les autorisations Linux.
Une introduction aux autorisations Linux
Comprendre les autorisations de fichiers Linux
Le modèle de sécurité Android évolue pour répondre aux besoins des utilisateurs qui non seulement ne comprennent généralement rien du modèle de sécurité sous-jacent du système d'exploitation, mais ne comprennent pratiquement rien des ordinateurs.
Le modèle Linux (que j'aime beaucoup plus) est conçu pour permettre aux utilisateurs (et aux administrateurs en particulier) d'exercer plus de contrôle sur la sécurité du système (dans les limites si leurs autorisations le permettent).
Du point de vue de l'utilisateur, il est préférable de décrire la différence entre un contrôle entièrement automatique et semi-automatique ou manuel. Les consommateurs modernes veulent une auto complète. Linux a semi-automatique et manuel. La plupart des utilisateurs de Linux n'ont jamais besoin de connaître le modèle de sécurité de nos jours, mais le contrôle est là si vous en avez besoin ou si vous le souhaitez.
la source
Lorsque vous installez certains programmes, vous pouvez les installer dans votre propre espace utilisateur (c'est-à-dire autonomes dans votre répertoire personnel) et non à l'échelle du système. En tant que tel, il ne vous est pas demandé de privilèges de superutilisateur car vous n'en avez pas besoin pour installer un programme pour un usage personnel. Un programme ainsi installé ne pourrait en effet pas accéder aux fichiers non accordés à la permission "non propriétaire non membre du groupe peut lire cette" absence d'une élévation de privilèges.
la source