Le système Ubuntu ne demande-t-il pas un mot de passe usurpé?
Parfois, Ubuntu affiche la fenêtre suivante:
Cette fenêtre peut être provoquée par certains processus d'arrière-plan en cours d'exécution, comme une mise à jour automatique, ou un processus qui signale des bogues à Canonical qui se manifeste de cette façon:
Comme il s'agit de processus d'arrière-plan, la première fenêtre ne s'affiche pas en réponse à une action que j'ai effectuée moi-même, dans une situation où je m'attendais à ce que le système me demande le mot de passe. Cela signifie que:
Du point de vue de l'utilisateur, il n'y a aucune garantie que l'invite provienne du système d'exploitation; il peut s'agir de tout programme malveillant qui ne disposait que d'une autorisation limitée pour afficher une fenêtre et qui, en demandant mon mot de passe, aura un accès illimité à l'ensemble de la machine.
En demandant régulièrement à l'utilisateur un mot de passe, le système apprend à l'utilisateur que donner son mot de passe système chaque fois qu'une application le demande est une chose parfaitement naturelle à faire.
Mes questions sont:
Existe-t-il un mécanisme de sécurité sous Linux en général ou Ubuntu en particulier qui empêche toute application d'afficher une boîte de dialogue qui ressemble à celle du système, me demandant mon mot de passe?
Comment ces fenêtres devraient-elles être conçues pour accroître la sécurité de l'utilisateur? Pourquoi ne pas implémenter un système similaire à Windows ' Ctrl+Alt+Del à la connexion ?
Vos points sont tous bons et vous avez raison, mais avant de nous indigner, nous devons nous rappeler comment fonctionne le modèle de sécurité Linux et ce qu'il est conçu pour protéger.
N'oubliez pas que le modèle de sécurité Linux est conçu en pensant à un serveur multi-utilisateur uniquement terminal ou SSH. Windows est conçu avec un poste de travail d'utilisateur final à l'esprit (mais j'ai entendu dire que la dernière génération de Windows est plus conviviale pour les terminaux). En particulier, la convention Linux fait un meilleur travail d'application de sandboxing aux utilisateurs, tandis que dans Windows, tout ce qui est important s'exécute en tant que système, tandis que l'interface graphique Linux (X Server) aspire à la sécurité, et l'interface graphique Windows a des choses fantaisistes comme l'UAC intégré. Fondamentalement, Linux est (et a toujours été) d'abord un serveur et un poste de travail, tandis que Windows est l'inverse.
Modèles de sécurité
En ce qui concerne "l'OS" (c'est-à-dire le noyau), vous avez 7 consoles tty et un nombre illimité de connexions SSH (aka "sessions de connexion") - il se trouve que ubuntu est livré avec des scripts pour démarrer automatiquement l'interface graphique sur le tty7 session, mais pour le noyau c'est juste une autre application.
Les sessions de connexion et les comptes d'utilisateurs sont très bien mis en sandbox les uns des autres, mais Linux adopte un état d'esprit de sécurité dont vous n'avez pas besoin pour protéger un utilisateur contre lui-même. Dans ce modèle de sécurité, si votre compte est compromis par des logiciels malveillants, c'est une cause perdue, mais nous voulons toujours l'isoler des autres comptes pour protéger le système dans son ensemble.
Par exemple, les applications Linux ont tendance à créer un utilisateur à faible privilège comme Apache ou ftp qu'elles exécutent comme lorsqu'elles n'ont pas besoin de faire des tâches root. Si un attaquant parvient à prendre le contrôle d'un processus Apache en cours d'exécution, il peut perturber d'autres processus Apache, mais aura des problèmes pour passer aux processus ftp.
Notez que Windows adopte une approche fondamentalement différente ici, en grande partie grâce à la convention selon laquelle toutes les choses importantes s'exécutent en tant que système tout le temps. Un service malveillant sous Linux a moins de possibilités de faire de mauvaises choses qu'un processus malveillant s'exécutant en tant que système, donc Windows a besoin de faire des efforts supplémentaires pour protéger quelqu'un avec droits d'administrateur de "eux-mêmes".
Les environnements GUI et un serveur X qui n'a pas été conçu pour la sécurité jettent une clé dans ce modèle de sécurité.
Gnome gksudo vs Windows UAC et enregistreurs de frappe
Sous Windows, lorsqu'un processus utilisateur demande une élévation de privilèges, le noyau génère une invite protégée spéciale dont la mémoire et le bus clavier/souris sont isolés du reste du reste de l'environnement de bureau. Il peut le faire car l'interface graphique est intégrée au système d'exploitation. Sous Linux, l'interface graphique (serveur X) n'est qu'une autre application, et donc les invites de mot de passe appartiennent au processus qui les a invoquées, s'exécutant comme vous, partageant les autorisations de mémoire et un bus d'entrée avec toutes les autres fenêtres et processus s'exécutant comme vous.
L'invite root ne peut pas faire les choses fantastiques de l'UAC, comme verrouiller le clavier, car celles-ci doivent déjà être root ou nécessitent une refonte complète du serveur X (voir Wayland ci-dessous). Un catch-22 qui dans ce cas est un inconvénient de séparer l'interface graphique du noyau. Mais au moins, cela correspond au modèle de sécurité Linux.
Si nous devions réviser le modèle de sécurité pour y remédier en ajoutant du sandbox entre les invites de mot de passe et d'autres processus exécutés en tant qu'utilisateur dans la même session GUI, nous pourrions avoir à réécrire beaucoup de choses. À tout le moins, le noyau devrait prendre conscience de l'interface utilisateur graphique de manière à pouvoir créer des invites (ce qui n'est pas le cas aujourd'hui). L'autre exemple de référence est que tous les processus d'une session GUI partagent un bus clavier.
Regardez-moi écrire un enregistreur de frappe, puis appuyez sur certaines touches dans une fenêtre différente :
➜ ~ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech K400 Plus id=9 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
➜ ~ xinput test 9
key release 36
key press 44
hkey release 44
key press 40
ekey release 40
key press 33
lkey release 33
key press 33
lkey press 39
okey release 33
key release 39
key press 66
key press 31
Tout processus en cours d'exécution comme vous pouvez renifler le mot de passe dans l'invite ou le terminal d'un autre processus, puis appeler Sudo sur lui-même (cela découle directement de l'état d'esprit "pas besoin de vous protéger contre vous"), donc augmenter la sécurité des invites de mot de passe est inutile à moins que nous changeons fondamentalement le modèle de sécurité et faisons une réécriture massive de toutes sortes de choses.
(il convient de noter que Gnome semble au moins sandboxer le bus clavier sur l'écran de verrouillage et les nouvelles sessions via "Changer d'utilisateurs" car les choses tapées là-bas n'apparaissent pas dans le bus clavier de ma session)
Wayland
Wayland est un nouveau protocole qui vise à remplacer X11. Il verrouille les applications clientes afin qu'elles ne puissent pas voler d'informations ou affecter quoi que ce soit en dehors de leur fenêtre. La seule façon dont les clients peuvent communiquer entre eux en dehors de l'extérieur IPC est en passant par le compositeur qui les contrôle tous. Cela ne résout cependant pas le problème sous-jacent, et déplace simplement le besoin pour la confiance du compositeur.
Virtualisation et conteneurs
Si vous travaillez avec des technologies cloud, vous sautez probablement de haut en bas en disant "Docker est la réponse !!". En effet, le brownie pointe pour vous. Bien que Docker lui-même ne soit pas vraiment destiné à améliorer la sécurité (merci @SvenSlootweg), il indique l'utilisation de la conteneurisation et/ou de la virtualisation comme un transfert compatible avec l'architecture Linux actuelle.
Deux distributions linux remarquables qui sont construites avec l'isolement inter-processus à l'esprit:
Qubes OS qui exécute des applications de niveau utilisateur dans plusieurs machines virtuelles séparées en "domaines de sécurité" tels que le travail, les opérations bancaires, la navigation Web.
Android qui installe et exécute chaque application en tant qu'utilisateur à faible privilège distinct, obtenant ainsi une isolation au niveau du processus et une isolation du système de fichiers (chaque application est confinée dans son propre répertoire de base) entre les applications.
Conclusion: Du point de vue d'un utilisateur final, il n'est pas déraisonnable de s'attendre à ce que Linux se comporte de la même manière que Windows, mais c'est l'un de ces cas où vous devez comprendre un peu comment le le système sous-jacent fonctionne et pourquoi il a été conçu de cette façon. La simple modification de la mise en œuvre des invites de mot de passe n'accomplira rien tant qu'elle appartiendra à un processus qui vous appartient. Pour que Linux obtienne les mêmes comportements de sécurité que Windows dans le contexte d'une station de travail GUI mono-utilisateur, il faudrait repenser considérablement le système d'exploitation, donc il est peu probable que cela se produise, mais des choses comme Docker peuvent fournir une voie à suivre dans un environnement plus Linux. manière native.
Dans ce cas, la différence importante est que Linux est conçu au bas niveau pour être un serveur multi-utilisateurs et qu'ils prennent la décision de ne pas protéger un utilisateur d'eux-mêmes, tandis que Windows est conçu pour être un poste de travail mono-utilisateur, vous devez donc disposer de protections interprocessus dans une session de connexion. Il est également important de noter que sous Windows, l'interface graphique fait partie du système d'exploitation, tandis que sous Linux, l'interface graphique n'est qu'une autre application de niveau utilisateur.
Existe-t-il un mécanisme de sécurité sous Linux en général ou Ubuntu en particulier qui empêche toute application d'afficher une boîte de dialogue identique à celle du système, me demandant mon mot de passe?
Réponse rapide: Non.
Du point de vue de l'utilisateur, il n'y a aucune garantie que l'invite provienne du système d'exploitation; il pourrait s'agir de n'importe quel programme malveillant qui ne disposait que d'une autorisation limitée pour afficher une fenêtre et, en demandant mon mot de passe, aura un accès illimité à l'ensemble de la machine.
Si un programme malveillant se trouve sur l'ordinateur, peu importe le programme qui affiche la boîte de dialogue.
Si c'est le programme malveillant, eh bien, comme décrit dans la phrase suivante, il n'a même pas besoin de vous montrer une boîte de dialogue. S'il s'agit d'un programme légitime, le programme malveillant peut "regarder" la fenêtre et ce que vous y tapez, dans les environnements de serveur X (le terminal est meilleur).
Solution?
Si vous avez des raisons de croire qu'un programme n'est pas digne de confiance, le bac à sable (VM ou autres choses).
Sinon, ne demande pas de mots de passe. Cette boîte de dialogue est pratique pour les utilisateurs non techniques. Si vous êtes préoccupé par la sécurité, ou un administrateur d'organisations ou similaire, il n'est absolument pas nécessaire d'afficher une requête de mot de passe GUI. Configurez correctement les autorisations des comptes d'utilisateurs non root (oui ou non, mais sans demander) et n'utilisez pas de bureau en tant que root (à cause de cela, et parce que c'est une tentation d'utiliser root plus souvent que nécessaire).
En demandant régulièrement à l'utilisateur un mot de passe, le système apprend à l'utilisateur que donner son mot de passe système chaque fois qu'une application le demande est une chose parfaitement naturelle à faire.
Comme décrit, ne leur demandez tout simplement pas. En tant qu'administrateur, "vos" utilisateurs sont censés disposer d'autorisations clairement définies.
Et, à propos des mises à jour automatiques en tant qu'administrateur de l'organisation: êtes-vous fou :) Sérieusement, ne laissez pas beaucoup de clients Ubuntu mettre à jour les choses Randon à des moments aléatoires. Qu'en est-il des images centrales que vous maintenez et testez puis déployez; ou dans l'autre sens des choses comme Ansible?
Complètement indépendantes de la sécurité, les mises à jour peuvent casser les choses. Voilà pourquoi.
Oui. Ce n'est pas sûr!
Personnellement, j'annule toujours cette boîte de dialogue. Pas parce que ça pourrait être faux, mais parce que ça pourrait être réel.
Je suis censé accorder des privilèges élevés à "une application" simplement parce qu'elle demande? Non je ne pense pas.
Les mises à jour du système sont correctes, je les fais manuellement, mais cela m'énerve que le système de rapport d'erreurs l'exige. Mauvaise conception.
Le moyen le plus sûr de vous assurer que votre mot de passe n'a pas été espionné est d'utiliser la séquence SAK: alt-sysrq-k. Cela tuera tous les programmes sur le VT actuel (y compris X11) et init vous donnera une nouvelle invite de connexion. Les seules attaques que je connaisse impliquent de modifier la carte de clé du noyau ou de compromettre l'init lui-même, qui nécessitent déjà un accès root ou supérieur.
Il existe différentes façons un peu moins complètes (XTerm a le moyen d'accéder à l'option "entrée exclusive" de X11), selon la quantité de votre système en laquelle vous avez confiance, mais ... pourquoi ne devriez-vous pas pouvoir faire confiance à votre système?
La principale différence entre les modèles de sécurité Linux et Windows est que sous Linux, vous ne pas téléchargez simplement des exécutables aléatoires sur Internet et exécutez-les. (Certains efforts sont déployés pour empaqueter des applications Linux non fiables dans un bac à sable de type Android, mais personne ne les utilise.)