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.

Rappelez-vous que Linux Le modèle de sécurité est conçu avec un terminal multi-utilisateurs 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 dernière génération de Windows est plus conviviale pour les terminaux). En particulier, la convention Linux fait un meilleur travail de sandboxing des applications dans les utilisateurs, tandis que dans Windows tout ce qui est important fonctionne en tant que système, tandis que l'interface graphique Linux (X Server) aspire à la sécurité, et l'interface graphique Windows a des éléments sophistiqués 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é

Pour autant que "le OS "(c'est-à-dire le noyau) est concerné, vous avez 7 consoles tty et un nombre quelconque 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, ce n’est qu’une autre application.

Les sessions de connexion et les comptes utilisateur 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 avec lequel ils s'exécutent lorsqu'ils n'ont pas besoin de faire des choses rooty. Si un attaquant parvient à prendre le contrôle d'un processus apache en cours d'exécution, il peut brouiller d'autres processus apache , mais aura des difficultés à passer aux processus ftp .

Notez que Windows adopte ici une approche fondamentalement différente, en grande partie à travers 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 s'exécutant en tant que système, donc Windows doit déployer des efforts supplémentaires pour protéger une personne disposant de droits d'administrateur contre «elle-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 vs Windows UAC, et keyloggers

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 par conséquent, les invites de mot de passe appartiennent au processus qui les a appelées, s'exécutant en tant que vous, partageant les autorisations de mémoire et un bus d'entrée avec chaque autre fenêtre et processus s'exécutant en tant que vous.

L'invite root ne peut pas faire les choses fantaisistes de l'UAC comme verrouiller le clavier parce que celles-ci doivent être déjà 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 la séparation de 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 lutter contre cela en ajoutant un sandbox entre les invites de mot de passe et d'autres processus s'exécutant en tant qu'utilisateur dans la même session GUI , nous pourrions avoir à réécrire beaucoup de choses. Au moins, le noyau devrait devenir conscient de l'interface graphique afin qu'il soit capable de créer des invites (ce n'est pas vrai aujourd'hui). L'autre exemple incontournable est que tous les processus d'une session GUI partagent un bus de clavier.

Regardez-moi écrire un keylogger puis appuyez sur quelques touches dans une autre fenêtre :

  ➜ ~ xinput list
⎡ Pointeur de noyau virtuel id = 2 [pointeur maître (3)] ⎜ ↳ Pointeur XTEST de noyau virtuel id = 4 [pointeur esclave (2)] ⎜ ↳ Logitech K400 Plus id = 9 [pointeur esclave (2)] ⎜ ↳ ETPS / 2 Elantech Touchpad id = 13 [pointeur esclave (2)] ➜ ~ x test d'entrée Déclenchement de 9 touches 36 pression de touche 44 hdéclenchement de touche 44 appui de touche 40 relâchement de touche 40 appui de touche 33 l relâchement de touche 33 appui de touche 33 appui de touche 39 relâchement okey 33 relâchement de touche 39 touche appuyez sur 66 touche appuyez sur 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 du "pas besoin de vous protéger contre vous "état d'esprit), donc augmenter la sécurité des invites de mot de passe est inutile à moins que nous ne changions fondamentalement le modèle de sécurité et ne réécrivions massivement toutes sortes de choses.

(il convient de noter que Gnome semble au moins sandbox le bus de clavier sur l'écran de verrouillage et la nouvelle session s via "Changer d'utilisateur" car les éléments qui y sont saisis 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 des informations ou affecter quoi que ce soit en dehors de leur fenêtre. La seule façon pour les clients de 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 transfère simplement le besoin de confiance au compositeur.

Virtualisation et conteneurs

Si vous travaillez avec des technologies cloud, vous ' re sautant 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 une avancée compatible avec l'architecture Linux actuelle.

Deux distributions Linux notables, conçues en tenant compte de l'isolement inter-processus:

Qubes OS qui exécute des applications au niveau de l'utilisateur dans plusieurs VM séparées en "domaines de sécurité" tels comme travail, banque, navigation Web.

Android qui installe et exécute chaque application en tant qu'utilisateur à faible privilège distinct, obtenant ainsi une isolation au niveau des processus et du système de fichiers (chacun est confiné à son propre répertoire personnel) 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. Le simple fait de changer 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, donc il est peu probable que cela se produise, mais des choses comme Docker peuvent fournir une voie à suivre dans un Linux plus. de 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, alors 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 dans 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 Ubuntu en particulier qui empêche toute application d'afficher une boîte de dialogue qui semble 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 provient 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 demandant mon mot de passe, obtiendra un accès illimité à l'ensemble de la machine.

Si un programme malveillant est activé l'ordinateur, peu importe le programme qui affiche la boîte de dialogue.
S'il s'agit d'un 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 des 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, faites du sandbox (VM ou des choses moins importantes).

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 par 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 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 son 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 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 des 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épendant 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 sont correctes, je les fais manuellement, mais cela m'ennuie que le système de rapport d'erreurs l'exige. Mauvaise conception.

Contrairement à ce que vous pensez, les méthodes (modernes) de Windows et d'Ubuntu pour gérer les niveaux de privilèges et l'élévation des privilèges sont assez similaires. La raison en est sûrement que les systèmes d'exploitation sont tous deux des systèmes multi-utilisateurs avec des cas d'utilisation similaires qui font face à des problèmes similaires.

Les deux systèmes d'exploitation restreignent ce qu'un utilisateur ordinaire peut faire (en exécutant des programmes, bien sûr). Un utilisateur peut détruire ses propres données, mais idéalement pas les autres (sauf s'il les a partagées), et idéalement ne peut pas compromettre ou endommager le système. Afin de lire et d'écrire des données système, un programme a besoin des privilèges d'administrateur (root) sur les deux systèmes d'exploitation, que seuls les programmes démarrés par l'administrateur / root ont habituellement.

Afin de rendre cela simple, les deux systèmes d'exploitation fournissent à l'utilisateur par défaut la possibilité d'exécuter des programmes uniques avec des "privilèges élevés" via sudo ou UAC. Les deux interfaces graphiques du système d'exploitation déclenchent une boîte de dialogue afin de donner à l'utilisateur une chance d'empêcher les programmes de s'exécuter en tant qu'administrateur / root. Les deux systèmes ont également la notion d'utilisateurs qui ne sont pas du tout autorisés à exécuter des programmes privilégiés.

La boîte de dialogue Ubuntu demande un mot de passe; la boîte de dialogue Windows UAC ne le fait pas. (Vous semblez penser qu'un programme a besoin d'autorisations spéciales pour afficher cette boîte de dialogue; ce n'est pas le cas. Le programme les demande avec la boîte de dialogue. Si quelqu'un simule la boîte de dialogue, il obtient votre (utilisateur) mot de passe, ce qui n’est pas un gain pour un programme qui s’exécute déjà sous cet utilisateur.)

En fin de compte, un programme malveillant peut prétendre qu’il a besoin de privilèges élevés pour quelque chose d’utile et déclencher le dialogue, mais une fois qu'il les a obtenus, formatez le disque dur. ¹ C'est vrai pour les deux systèmes d'exploitation. Parce que sous Windows, généralement plus de logiciels tiers sont installés, la chance de frapper un tel programme est probablement plus élevée que pour Ubuntu.

Vous mentionnez que dans Windows, la boîte de dialogue UAC est généralement le résultat d'une action de l'utilisateur, par exemple l'installation d'un programme, tandis qu'Ubuntu déclenche la boîte de dialogue sans raison apparente. Une raison à laquelle je peux penser est que les mises à jour logicielles Windows sont initiées par le système d'exploitation afin qu'elles aient déjà des privilèges élevés. Peut-être qu'Ubuntu demande avant l'installation.

Ce serait vraiment bien d'avoir plus d'informations que simplement "J'ai besoin de votre passeport, de vos bottes et de votre veste". Je n'ai pas de système Ubuntu sous la main ici, mais je vois une légende «Détails» sur le côté gauche de la boîte de dialogue. Avez-vous regardé ce qui est dit? (Bien sûr, un programme malveillant pourrait simuler n'importe quel texte, mais vous pourrez peut-être vérifier si le programme présumé est effectivement en cours d'exécution.)

Le moyen le plus sûr de s'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 dont je suis au courant impliquent soit de modifier le keymap du noyau, soit de compromettre init lui-même, qui nécessitent déjà un accès root ou supérieur.

Il existe plusieurs moyens légèrement moins complets (XTerm a moyen d'accéder à l'option «entrée exclusive» de X11), en fonction de la quantité de votre système en laquelle vous faites confiance, mais ... pourquoi ne devriez-vous pas pouvoir faire confiance à votre système?

La différence majeure entre Linux et les modèles de sécurité Windows sont que sous Linux, vous ne vous contentez pas de télécharger des exécutables aléatoires depuis Internet et de les exécuter. (Il y a des efforts pour empaqueter des applications Linux non approuvées dans un bac à sable de type Android, mais personne ne les utilise.)

Horrible, horrible manque de sécurité. Quand j'ai vu la conception du sudo graphique, j'ai mordu la balle et j'ai fait sudo passwd root suivi de apt-get remove sudo , alors j'ai vraiment énervé les gens d'ubuntu IRC en préconisant la désinstallation sudo.

Pourtant, je comprends toujours, ce n'est absolument pas sûr. C'était plutôt correct sur le terminal (d'autant plus quand les shells étaient plus faibles, c'était relativement inconnu et les attaques contre lui ne s'étaient pas vraiment développées) mais c'est un point faible flagrant maintenant.

Je vais plutôt démarrer une deuxième instance X en tant que root maintenant pour moins d'une fois par an, je dois donner une racine de programme graphique. (Je fais cela en démarrant X: 1 directement pas en exécutant startx donc rien d'autre que l'application cible ne s'exécute dans l'instance X de root). Si vous avez besoin de root plus souvent, je vous conseille apt-get install ssh et ssh -X root @ localhost .