Ist die Systemabfrage von Ubuntu zur Eingabe meines Passworts nicht fälschbar?

Ihre Punkte sind alle gut und Sie haben Recht, aber bevor wir uns darüber aufregen, müssen wir uns daran erinnern, wie das Linux-Sicherheitsmodell funktioniert und was es schützen soll.

Denken Sie daran, dass das Linux-Sicherheitsmodell nur für Mehrbenutzer-Terminals oder SSH-Server konzipiert ist. Windows ist für eine Endbenutzer-Workstation konzipiert (aber ich habe gehört, dass die neueste Windows-Generation Terminal-freundlicher ist). Insbesondere die Linux-Konvention leistet bessere Arbeit beim Sandboxing von Apps für Benutzer, während in Windows alles Wichtige als System ausgeführt wird, während die Linux-GUI (X Server) die Sicherheit beeinträchtigt und die Windows-GUI ausgefallene Dinge wie UAC integriert hat. Grundsätzlich ist (und war) Linux zuerst ein Server und dann eine Workstation, während Windows umgekehrt ist.

Sicherheitsmodelle

Was "das Betriebssystem" (dh den Kernel) betrifft, haben Sie 7 tty-Konsolen und eine beliebige Anzahl von SSH-Verbindungen (auch bekannt als "Anmeldesitzungen") - es kommt einfach so vor, dass Ubuntu mit Skripten zum automatischen Starten der GUI ausgeliefert wird der tty7 Session, aber für den Kernel ist es nur eine weitere Anwendung.

Anmeldesitzungen und Benutzerkonten sind ziemlich gut voneinander abgegrenzt, aber Linux nimmt eine Sicherheitseinstellung an, die Sie nicht brauchen, um einen Benutzer vor sich selbst zu schützen. Wenn Ihr Konto bei diesem Sicherheitsmodell durch Malware kompromittiert wird, ist dies ein hoffnungsloser Fall, aber wir möchten es dennoch von anderen Konten isolieren, um das System als Ganzes zu schützen.

Beispielsweise neigen Linux-Apps dazu, einen Benutzer mit geringen Berechtigungen wie apache zu erstellen oder ftp dass sie so laufen, als ob sie keine wurzeligen Dinge tun müssten. Wenn es einem Angreifer gelingt, die Kontrolle über ein laufendes apache zu übernehmen verarbeiten, kann es andere apache vermasseln Prozesse, wird aber Schwierigkeiten haben, zu ftp zu springen Prozesse.

Beachten Sie, dass Windows hier einen grundlegend anderen Ansatz verfolgt, hauptsächlich durch die Konvention, dass alle wichtigen Dinge die ganze Zeit als System ausgeführt werden. Ein bösartiger Dienst in Linux hat weniger Spielraum, um schlechte Dinge zu tun, als ein bösartiger Prozess, der als System ausgeführt wird, also muss zusätzliche Anstrengungen zu unternehmen, um jemanden mit Administratorrechten vor „sich selbst“ zu schützen.

GUI-Umgebungen und ein X-Server, der nicht auf Sicherheit ausgelegt ist, machen diesem Sicherheitsmodell einen Strich durch die Rechnung.

Gnome gksudo vs. Windows UAC und Keylogger

Wenn in Windows ein Benutzerprozess eine Privilegienausweitung anfordert, wirft der Kernel eine spezielle geschützte Eingabeaufforderung auf, deren Speicher und Tastatur-/Mausbus vom Rest der Desktop-Umgebung isoliert sind. Dies ist möglich, da die GUI in das Betriebssystem integriert ist. Unter Linux ist die GUI (X-Server) nur eine weitere Anwendung, und daher gehören die Passwortabfragen zu dem Prozess, der sie aufgerufen hat, der als Sie ausgeführt wird, Speicherberechtigungen und einen Eingabebus mit jedem anderen Fenster und Prozess teilt, der als Sie ausgeführt wird.

Die Root-Eingabeaufforderung kann die ausgefallenen UAC-Dinge wie das Sperren der Tastatur nicht ausführen, da diese entweder bereits als Root angemeldet sein müssen oder den X-Server vollständig neu entwerfen müssen (siehe Wayland unten). Ein Catch-22, der in diesem Fall ein Nachteil der Trennung der GUI vom Kernel ist. Aber zumindest entspricht es dem Linux-Sicherheitsmodell.

Wenn wir das Sicherheitsmodell überarbeiten würden, um dies einzudämmen, indem wir Sandboxing zwischen Passwortabfragen und anderen Prozessen hinzufügen, die als Benutzer in derselben GUI-Sitzung ausgeführt werden, müssten wir möglicherweise sehr viele Dinge neu schreiben. Zumindest müsste der Kernel GUI-fähig werden, damit er Eingabeaufforderungen erstellen kann (heute nicht zutreffend). Das andere Beispiel ist, dass alle Prozesse in einer GUI-Sitzung einen Tastaturbus gemeinsam nutzen.

Sehen Sie mir zu, wie ich einen Keylogger schreibe und dann in einem anderen Fenster einige Tasten drücke :

➜  ~ 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

Jeder Prozess, der ausgeführt wird, da Sie das Passwort in der Eingabeaufforderung oder im Terminal eines anderen Prozesses erschnüffeln und dann sudo für sich selbst aufrufen können (dies folgt direkt aus der Denkweise "Sie müssen nicht vor Ihnen geschützt werden"), sodass die Erhöhung der Sicherheit der Passworteingabeaufforderungen nutzlos ist, es sei denn Wir ändern das Sicherheitsmodell grundlegend und schreiben alle möglichen Dinge massiv neu.

(Es ist erwähnenswert, dass Gnome anscheinend zumindest den Tastaturbus auf dem Sperrbildschirm und neue Sitzungen über „Benutzer wechseln“ sandboxt, da die dort eingegebenen Dinge nicht im Tastaturbus meiner Sitzung angezeigt werden)

Wayland

Wayland ist ein neues Protokoll, das darauf abzielt, X11 zu ersetzen. Es sperrt Client-Anwendungen, sodass sie keine Informationen stehlen oder irgendetwas außerhalb ihres Fensters beeinflussen können. Die einzige Möglichkeit, wie die Clients außerhalb des externen IPC miteinander kommunizieren können, besteht darin, den Compositor zu durchlaufen, der sie alle steuert. Dies behebt jedoch nicht das zugrunde liegende Problem und verlagert einfach die Notwendigkeit des Vertrauens auf den Compositor.

Virtualisierung und Container

Wenn Sie mit Cloud-Technologien arbeiten, hüpfen Sie wahrscheinlich auf und ab und sagen:„Docker ist die Antwort!“. In der Tat, Brownie-Punkte für Sie. Obwohl Docker selbst nicht wirklich dazu gedacht ist, die Sicherheit zu verbessern (danke @SvenSlootweg), weist es auf die Verwendung von Containerisierung und/oder Virtualisierung als Vorwärtsmaßnahme hin, die mit der aktuellen Linux-Architektur kompatibel ist.

Zwei bemerkenswerte Linux-Distributionen, die im Hinblick auf die Isolierung zwischen Prozessen erstellt wurden:

Qubes-Betriebssystem die Apps auf Benutzerebene in mehreren VMs ausführt, die in "Sicherheitsdomänen" wie Arbeit, Banking, Webbrowsing unterteilt sind.

Android das jede App als separaten Benutzer mit geringen Berechtigungen installiert und ausführt, wodurch eine Isolierung auf Prozessebene und Dateisystemisolierung (jede App ist auf ihr eigenes Home-Verzeichnis beschränkt) zwischen Apps erreicht wird.

Fazit: Aus der Sicht eines Endbenutzers ist es nicht unvernünftig zu erwarten, dass sich Linux genauso verhält wie Windows, aber dies ist einer der Fälle, in denen Sie ein wenig verstehen müssen, wie das zugrunde liegende System funktioniert und warum es so konzipiert wurde . Das einfache Ändern der Implementierung der Kennworteingabeaufforderungen wird nichts bewirken, solange es einem Prozess gehört, der Ihnen gehört. Damit Linux das gleiche Sicherheitsverhalten wie Windows im Kontext einer Einzelbenutzer-GUI-Workstation erhält, wäre eine erhebliche Neugestaltung des Betriebssystems erforderlich, daher ist dies unwahrscheinlich, aber Dinge wie Docker können einen Weg nach vorne in einer Linux-orientierteren Umgebung bieten. native Weise.

In diesem Fall besteht der wichtige Unterschied darin, dass Linux auf niedriger Ebene als Mehrbenutzerserver konzipiert ist und sie die Entscheidung treffen, einen Benutzer nicht vor sich selbst zu schützen, während Windows als Einzelbenutzer-Workstation konzipiert ist. Daher müssen Sie innerhalb einer Anmeldesitzung prozessübergreifenden Schutz haben. Es ist auch relevant, dass die GUI in Windows Teil des Betriebssystems ist, während die GUI in Linux nur eine weitere Anwendung auf Benutzerebene ist.

Gibt es einen Sicherheitsmechanismus in Linux im Allgemeinen oder Ubuntu im Besonderen, der verhindert, dass eine Anwendung einen Dialog anzeigt, der identisch mit dem des Systems aussieht und mich nach meinem Passwort fragt?

Schnelle Antwort:Nein.

Aus Sicht des Benutzers gibt es keine Garantie dafür, dass die Eingabeaufforderung vom Betriebssystem kommt; es könnte jedes bösartige Programm sein, das nur eine begrenzte Berechtigung zum Anzeigen eines Fensters hatte und durch die Aufforderung zur Eingabe meines Passworts unbegrenzten Zugriff auf den gesamten Computer erhält.

Wenn sich ein Schadprogramm auf dem Computer befindet, spielt es keine Rolle, welches Programm den Dialog anzeigt.
Wenn es sich um das Schadprogramm handelt, muss es Ihnen, wie im nächsten Satz beschrieben, nicht einmal einen Dialog anzeigen. Wenn es sich um ein legitimes Programm handelt, kann das bösartige Programm das Fenster und Ihre Eingaben in X-Server-Umgebungen (das Terminal ist besser) "beobachten".

Lösung?

Wenn Sie Grund zu der Annahme haben, dass ein Programm nicht vertrauenswürdig ist, Sandboxing (VM oder kleinere Dinge).

Sonst fragt nicht nach Passwörtern . Dieser Dialog ist praktisch für technisch nicht versierte Benutzer. Wenn Sie sich Sorgen um die Sicherheit machen oder ein Organisationsadministrator oder ähnliches ist, besteht absolut keine Notwendigkeit, jemals eine GUI-Passwortabfrage anzuzeigen. Konfigurieren Sie die Berechtigungen von Nicht-Root-Benutzerkonten richtig (ja oder nein, aber nicht fragen) und verwenden Sie keinen Desktop als Root (aus diesem Grund und weil es eine Versuchung ist, Root öfter als nötig zu verwenden).

Indem der Benutzer regelmäßig nach dem Passwort gefragt wird, lehrt das System den Benutzer, dass es ganz natürlich ist, sein Systempasswort immer dann anzugeben, wenn eine Anwendung danach fragt.

Wie beschrieben, einfach nicht fragen. Als Admin sollen "Ihre" Benutzer klar definierte Rechte haben.

Und bezüglich automatischer Updates als Organisationsadministrator:Bist du verrückt :) Im Ernst, lass nicht zu, dass viele Ubuntu-Clients willkürlich Dinge zu zufälligen Zeiten aktualisieren. Wie wäre es mit zentralen Images, die von Ihnen gepflegt und getestet und dann ausgerollt werden; oder in die andere Richtung Sachen wie Ansible?
Völlig unabhängig von der Sicherheit können Updates Dinge beschädigen. Deshalb.

Ja. Das ist unsicher!

Ich persönlich breche diesen Dialog immer ab. Nicht weil es gefälscht sein könnte, sondern weil es echt sein könnte.

Ich soll "einer Anwendung" eskalierte Privilegien geben, nur weil sie danach fragt? Nein, das glaube ich nicht.

Systemaktualisierungen sind in Ordnung, ich mache diese manuell, aber es ärgert mich, dass das Fehlermeldesystem dies erfordert. Schlechtes Design.