it-swarm.com.de

Ist Ubuntus Systemaufforderung zur Eingabe meines Passworts nicht fälschbar?

Manchmal zeigt Ubuntu das folgende Fenster:

(Screen shot of "Authenticate" dialog box asking for password

Dieses Fenster kann durch einige Hintergrundprozesse verursacht werden, die ausgeführt werden, z. B. ein automatisches Update oder ein Prozess, der Fehler an Canonical meldet, die sich folgendermaßen manifestieren:

(Screen shot of "System program problem detected" query box

Da es sich um Hintergrundprozesse handelt, wird das erste Fenster nicht als Reaktion auf eine von mir selbst ausgeführte Aktion angezeigt, in einer Situation, in der ich erwartet hatte, dass das System mich nach dem Kennwort fragt. Das bedeutet, dass:

  • Aus Sicht des Benutzers gibt es keine Garantie dafür, dass die Eingabeaufforderung vom Betriebssystem stammt. Es kann sich um ein beliebiges Schadprogramm handeln, das nur über eine eingeschränkte Berechtigung zum Anzeigen eines Fensters verfügt und durch Aufforderung zur Eingabe meines Kennworts uneingeschränkten Zugriff auf den gesamten Computer erhält.

  • Indem der Benutzer regelmäßig zur Eingabe eines Kennworts aufgefordert wird, lehrt das System den Benutzer, dass es selbstverständlich ist, sein Systemkennwort zu geben, wenn eine Anwendung danach fragt.

Meine Fragen sind:

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

  • Wie sollten solche Fenster gestaltet werden, um die Sicherheit des Benutzers zu erhöhen? Warum nicht ein System implementieren, das Windows ähnelt? Ctrl+Alt+Del bei Anmeldung ?

189

Ihre Punkte sind alle gut und Sie haben Recht, aber bevor wir uns darüber empören, 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 wurde speziell für Endbenutzer-Workstations entwickelt (aber ich habe gehört, dass die neueste Windows-Generation terminalfreundlicher ist). Insbesondere macht die Linux-Konvention das Sandboxing von Apps für Benutzer besser, während unter 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 die integrierte Benutzerkontensteuerung enthält. 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 als "Anmeldesitzungen" bezeichnet) - es kommt nur so vor, dass Ubuntu mit Skripten geliefert wird, um die GUI automatisch zu starten das tty7 session, aber für den Kernel ist es nur eine andere Anwendung.

Anmeldesitzungen und Benutzerkonten sind recht gut voneinander getrennt, aber Linux geht von einer Sicherheitseinstellung aus, die Sie nicht benötigen, um einen Benutzer vor sich selbst zu schützen. Wenn in diesem Sicherheitsmodell Ihr Konto durch Malware kompromittiert wird, ist dies eine verlorene Ursache. Wir möchten es jedoch weiterhin von anderen Konten isolieren, um das gesamte System zu schützen.

Beispielsweise erstellen Linux-Apps in der Regel Benutzer mit geringen Berechtigungen wie Apache oder ftp, die so ausgeführt werden, als müssten sie keine Root-Aufgaben ausführen. Wenn es einem Angreifer gelingt, die Kontrolle über einen laufenden Apache -Prozess zu übernehmen, kann er andere Apache -Prozesse durcheinander bringen, hat jedoch Probleme beim Springen zu ftp -Prozessen.

Beachten Sie, dass Windows hier einen grundlegend anderen Ansatz verfolgt, hauptsächlich aufgrund der Konvention, dass alle wichtigen Dinge ständig als System ausgeführt werden. Ein bösartiger Dienst unter Linux hat weniger Möglichkeiten, schlechte Dinge zu tun als ein bösartiger Prozess, der als System ausgeführt wird. Daher muss Windows zusätzliche Anstrengungen unternehmen, um jemanden mit zu schützen Administratorrechte von "sich selbst".

GUI-Umgebungen und ein X-Server, der nicht für die Sicherheit ausgelegt ist, bieten einen Schlüssel für dieses Sicherheitsmodell.


Gnome gksudo vs Windows UAC und Keylogger

Wenn ein Benutzerprozess unter Windows eine Eskalation von Berechtigungen anfordert, löst der Kernel eine spezielle geschützte Eingabeaufforderung aus, deren Speicher und Tastatur-/Mausbus vom Rest der restlichen 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 andere Anwendung, und daher gehören die Kennwortabfragen zu dem Prozess, der sie aufgerufen hat. Sie werden wie Sie ausgeführt, teilen Speicherberechtigungen und einen Eingabebus mit jedem anderen Fenster und Prozess, der wie Sie ausgeführt wird.

Die Root-Eingabeaufforderung kann nicht die ausgefallenen UAC-Dinge ausführen, die die Tastatur sperren, da diese entweder bereits root sein müssen oder den X-Server komplett neu entwerfen müssen (siehe Wayland unten). Ein Catch-22, der in diesem Fall ein Nachteil beim Trennen der GUI vom Kernel ist. Aber zumindest entspricht es dem Linux-Sicherheitsmodell.

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

Beobachten Sie, wie ich einen Keylogger schreibe und dann einige Tasten in einem anderen Fenster 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, während Sie das Kennwort in der Eingabeaufforderung oder im Terminal eines anderen Prozesses abhören und dann Sudo selbst aufrufen können (dies folgt direkt aus der Einstellung "Sie müssen nicht vor Ihnen geschützt werden"), sodass eine Erhöhung der Sicherheit der Kennwortansagen nur dann sinnvoll ist Wir ändern das Sicherheitsmodell grundlegend und schreiben alle möglichen Dinge neu.

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


Wayland

Wayland ist ein neues Protokoll, das X11 ersetzen soll. Client-Anwendungen werden gesperrt, sodass sie keine Informationen stehlen oder irgendetwas außerhalb ihres Fensters beeinflussen können. Die Clients können nur außerhalb von extern miteinander kommunizieren IPC), indem sie den Compositor durchlaufen, der sie alle steuert. Dies behebt jedoch nicht das zugrunde liegende Problem und verschiebt einfach die Notwendigkeit für das Vertrauen an den Komponisten.


Virtualisierung und Container

Wenn Sie mit Cloud-Technologien arbeiten, springen Sie wahrscheinlich auf und ab und sagen "Docker ist die Antwort !!". In der Tat zeigt Brownie für Sie. Docker selbst soll zwar nicht wirklich die Sicherheit verbessern (danke @SvenSlootweg), weist jedoch darauf hin, Containerisierung und/oder Virtualisierung als Forward zu verwenden, das mit der aktuellen Linux-Architektur kompatibel ist.

Zwei bemerkenswerte Linux-Distributionen, die unter Berücksichtigung der Prozessisolation erstellt wurden:

Qubes OS, mit dem Apps auf Benutzerebene in mehreren VMs ausgeführt werden, die in "Sicherheitsdomänen" wie Arbeit, Bankwesen und Surfen im Internet unterteilt sind.

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


Fazit : Aus der Sicht eines Endbenutzers ist es nicht unangemessen 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 funktioniert Das zugrunde liegende System funktioniert und warum es so konzipiert wurde. Durch einfaches Ändern der Implementierung der Kennwortansagen wird nichts erreicht, solange es sich um einen Prozess handelt, der Ihnen gehört. Damit Linux im Kontext einer Einzelbenutzer-GUI-Workstation das gleiche Sicherheitsverhalten wie Windows aufweist, muss das Betriebssystem erheblich neu gestaltet werden. Daher ist es unwahrscheinlich, dass dies geschieht. Dinge wie Docker bieten jedoch möglicherweise einen Weg nach vorne in einem Linux-System. native Weise.

In diesem Fall besteht der wichtige Unterschied darin, dass Linux auf niedriger Ebene als Mehrbenutzerserver konzipiert ist und die Entscheidung getroffen wird, einen Benutzer nicht vor sich selbst zu schützen, während Windows als Einzelbenutzerarbeitsstation konzipiert ist. Daher müssen Sie innerhalb einer Anmeldesitzung prozessübergreifend geschützt sein. Es ist auch wichtig, dass unter Windows die GUI Teil des Betriebssystems ist, während unter Linux die GUI nur eine weitere Anwendung auf Benutzerebene ist.

192
Mike Ounsworth

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

Schnelle Antwort: Nein.

Aus Sicht des Benutzers gibt es keine Garantie dafür, dass die Eingabeaufforderung vom Betriebssystem stammt. Es kann sich um ein beliebiges Schadprogramm handeln, das nur eine eingeschränkte Berechtigung zum Anzeigen eines Fensters hatte und durch Aufforderung zur Eingabe meines Kennworts uneingeschränkten 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 ein Schadprogramm handelt, wie im nächsten Satz beschrieben, muss es Ihnen nicht einmal einen Dialog anzeigen. Wenn es sich um ein legitimes Programm handelt, kann das Schadprogramm das Fenster und das, was Sie dort eingeben, in X-Server-Umgebungen "beobachten" (das Terminal ist besser).

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 für nicht technische Benutzer praktisch. Wenn Sie Sicherheitsbedenken haben oder ein Administrator oder ähnliches, müssen Sie auf keinen Fall eine GUI-Kennwortabfrage anzeigen. Konfigurieren Sie die Berechtigungen von Nicht-Root-Benutzerkonten ordnungsgemäß (Ja oder Nein, aber nicht nachfragen) und verwenden Sie keinen Desktop als Root (aus diesem Grund und weil es eine Versuchung ist, Root häufiger als nötig zu verwenden).

Indem der Benutzer regelmäßig zur Eingabe eines Kennworts aufgefordert wird, lehrt das System den Benutzer, dass es eine ganz natürliche Sache ist, sein Systemkennwort zu geben, wenn eine Anwendung danach fragt.

Wie beschrieben, frag sie einfach nicht. Als Administrator sollen "Ihre" Benutzer klar definierte Berechtigungen haben.

Und zu automatischen Updates als Organisationsadministrator: Sind Sie verrückt :) Im Ernst, lassen Sie nicht zu, dass viele Ubuntu-Clients zufällige Dinge zu zufälligen Zeiten aktualisieren. Wie wäre es mit zentralen Bildern, die von Ihnen verwaltet und getestet und dann ausgerollt werden? oder in die andere Richtung Dinge wie Ansible?
Völlig unabhängig von der Sicherheit können Aktualisierungen Probleme verursachen. Deshalb.

33
deviantfan

Ja. Das ist unsicher!

Ich persönlich brich diesen Dialog immer ab. Nicht weil es falsch sein könnte, sondern weil es echt sein könnte.

Ich soll "einer Anwendung" eskalierte Berechtigungen erteilen, nur weil sie fragt? Nein, das glaube ich nicht.

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

22
Stig Hemmer

Der sicherste Weg, um sicherzustellen, dass Ihr Passwort nicht abgehört wurde, ist die Verwendung der SAK-Sequenz: alt-sysrq-k. Dadurch werden alle Programme auf dem aktuellen VT (einschließlich X11) beendet, und init gibt Ihnen eine neue Anmeldeaufforderung. Die einzigen mir bekannten Angriffe betreffen entweder das Ändern der Kernel-Keymap oder das Kompromittieren von init selbst. Beide erfordern bereits Root-oder-Better-Zugriff.

Es gibt verschiedene, etwas weniger vollständige Möglichkeiten (XTerm hat die Möglichkeit, auf die Option "Exklusive Eingabe" von X11 zuzugreifen), je nachdem, wie viel von Ihrem System Sie vertrauen, aber ... warum sollten Sie Ihrem System nicht vertrauen können?

Der Hauptunterschied zwischen den Sicherheitsmodellen Linux und Windows besteht darin, dass Sie unter Linux nicht nur zufällige ausführbare Dateien aus dem Internet herunterladen und ausführen. (Es gibt einige Bemühungen, nicht vertrauenswürdige Linux-Anwendungen in eine Android-ähnliche Paket-Sandbox zu packen, aber niemand verwendet sie.)

5
o11c