Vos points sont tous bons et vous avez raison, mais avant de nous en 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 avec un terminal multi-utilisateur uniquement ou un serveur SSH à l'esprit. Windows est conçu avec un poste de travail d'utilisateur final à l'esprit (mais j'ai entendu dire que la génération récente de Windows est plus conviviale pour les terminaux). En particulier, la convention Linux fait un meilleur travail de mise en sandbox des applications dans les 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) craint la sécurité, et l'interface graphique Windows a des choses fantaisistes comme UAC intégré. Fondamentalement, Linux est (et a toujours été) un serveur d'abord et un poste de travail ensuite, tandis que Windows est l'inverse.
Modèles de sécurité
En ce qui concerne "le système d'exploitation" (c'est-à-dire le noyau), vous avez 7 consoles tty et un nombre quelconque de connexions SSH (alias "sessions de connexion") - il se trouve qu'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 assez bien séparés les uns des autres, mais Linux adopte un état d'esprit de sécurité selon lequel vous n'avez pas besoin de protéger un utilisateur d'eux-mêmes. 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'ils courent comme lorsqu'ils n'ont pas besoin de faire des choses rooty. Si un attaquant parvient à prendre le contrôle d'un apache en cours d'exécution processus, il peut gâcher d'autres apache processus, mais aura des problèmes pour passer à ftp processus.
Notez que Windows adopte ici une approche fondamentalement différente, en grande partie par la convention selon laquelle toutes les choses importantes fonctionnent 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 exécuté en tant que système, donc Windows a besoin faire des efforts supplémentaires pour protéger quelqu'un avec des droits d'administrateur de « lui-même ».
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 contre Windows UAC et les enregistreurs de frappe
Sous Windows, lorsqu'un processus utilisateur demande une élévation de privilèges, le noyau lance une invite spéciale protégée 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 en tant que vous, partageant les autorisations de mémoire et un bus d'entrée avec toutes les autres fenêtres et processus en cours d'exécution en tant que vous.
L'invite root ne peut pas faire les choses fantaisistes UAC comme verrouiller le clavier car celles-ci doivent déjà être root ou nécessitent une refonte totale 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, c'est conforme au modèle de sécurité Linux.
Si nous devions réviser le modèle de sécurité pour y remédier en ajoutant un sandboxing entre les invites de mot de passe et d'autres processus exécutés en tant qu'utilisateur dans la même session d'interface graphique, nous pourrions avoir à réécrire un grand nombre de choses. Au moins, le noyau devrait devenir conscient de l'interface graphique de sorte qu'il soit capable de 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 autre fenêtre :
➜ ~ 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 car 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 de 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 procédons à une réécriture massive de toutes sortes de choses.
(il convient de noter que Gnome semble au moins mettre en bac à sable le bus du clavier sur l'écran de verrouillage et les nouvelles sessions via "Changer d'utilisateur" car les éléments saisis ici n'apparaissent pas dans le bus du 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 des 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'IPC extérieur est de passer par le compositeur qui les contrôle tous. Cependant, cela ne résout pas le problème sous-jacent et déplace simplement le besoin de confiance vers le compositeur.
Virtualisation et conteneurs
Si vous travaillez avec des technologies cloud, vous sautez probablement de joie en disant "Docker est la réponse !!". En effet, des points brownie 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 notables conçues avec l'isolation inter-processus à l'esprit :
Qubes OS qui exécute des applications au niveau de l'utilisateur à l'intérieur de plusieurs machines virtuelles séparées en "domaines de sécurité" tels que le travail, la banque, la navigation Web.
Android qui installe et exécute chaque application en tant qu'utilisateur séparé à faible privilège, obtenant ainsi une isolation au niveau du processus et une isolation du système de fichiers (chaque application est confinée à son propre répertoire d'accueil) 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 système sous-jacent fonctionne et pourquoi il a été conçu de cette façon. . Changer simplement l'implémentation des invites de mot de passe n'accomplira rien tant qu'il appartient à un processus qui vous appartient. Pour que Linux obtienne les mêmes comportements de sécurité que Windows dans le contexte d'un poste de travail GUI mono-utilisateur, il faudrait une refonte importante du système d'exploitation, il est donc peu probable que cela se produise, mais des choses comme Docker peuvent fournir une voie à suivre dans un plus Linux- manière native.
Dans ce cas, la différence importante est que Linux est conçu au niveau bas pour être un serveur multi-utilisateurs et ils prennent la décision de ne pas protéger un utilisateur contre lui-même, tandis que Windows est conçu pour être un poste de travail mono-utilisateur, vous devez donc disposer de protections inter-processus dans une session de connexion. Il est également pertinent que sous Windows, l'interface graphique fasse partie du système d'exploitation, tandis que sous Linux, l'interface graphique n'est qu'une autre application au niveau de l'utilisateur.
Existe-t-il un mécanisme de sécurité dans Linux en général ou dans 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 n'avait qu'une autorisation limitée pour afficher une fenêtre, et en me demandant mon mot de passe, obtiendrait 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.
S'il s'agit du 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 préférable).
La solution?
Si vous avez des raisons de croire qu'un programme n'est pas digne de confiance, faites du sandboxing (VM ou autres).
Sinon, ne pas demander 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'organisation 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 un bureau en tant que root (à cause de cela, et parce qu'il est tentant d'utiliser root plus souvent que nécessaire).
En demandant régulièrement à l'utilisateur de saisir son mot de passe, le système enseigne à l'utilisateur qu'il est parfaitement naturel de donner son mot de passe système chaque fois qu'une application le demande.
Comme décrit, ne leur demandez pas. En tant qu'administrateur, "vos" utilisateurs sont censés avoir des 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 de nombreux clients Ubuntu mettre à jour des choses aléatoires à des moments aléatoires. Que diriez-vous d'images centrales qui sont maintenues et testées par vous, puis déployées ? ou dans l'autre sens des choses comme Ansible ?
Complètement indépendantes de la sécurité, les mises à jour peuvent casser des choses. C'est pourquoi.
Oui. Ce n'est pas sûr !
Personnellement, j'annule toujours ce dialogue. Non pas parce que cela pourrait être faux, mais parce que cela pourrait être réel.
Je suis censé accorder des privilèges accrus à "une application" simplement parce qu'elle le demande ? Non, je ne pense pas.
Les mises à jour du système vont bien, je les fais manuellement, mais cela m'ennuie que le système de rapport d'erreurs l'exige. Mauvaise conception.