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 Linux Das Sicherheitsmodell wurde für einen Mehrbenutzer-Terminal- oder SSH-Server entwickelt. 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

Soweit "the OS "(dh der Kernel) ist betroffen, Sie haben 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 auf dem tty7 automatisch zu starten -Sitzung, 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 schützen müssen Benutzer von sich selbst. 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 tendieren Linux-Apps dazu Erstellen Sie einen Benutzer mit geringen Berechtigungen wie apache oder ftp , den er so ausführt, als ob er keine Root-Aufgaben ausführen müsste. 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 Administratorrechten vor "sich selbst" zu schützen.

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

Gnome gksudo gegen Windows-Benutzerkontensteuerung 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 dies dem Linux-Sicherheitsmodell.

Wenn wir das Sicherheitsmodell überarbeiten würden, um dies zu verhindern, indem wir Sandboxing zwischen Kennwortansagen und anderen Prozessen hinzufügen, die als Benutzer in derselben GUI-Sitzung ausgeführt werden Wir könnten sehr viele Dinge neu schreiben müssen. 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:

  x ~ xinput list
⎡ ID des virtuellen Kernzeigers = 2 [Hauptzeiger (3)] X XTEST-Zeiger-ID des virtuellen Kerns = 4 [Slave-Zeiger (2)] ite Logitech K400 Plus-ID = 9 [Slave-Zeiger (2)] ⎜ ETPS / 2 Elantech Touchpad id = 13 [Slave-Zeiger (2)] x ~ xinput test 9Tastenfreigabe 36 Tastendruck 44 Tastendruck 44 Tastendruck 40 Tastendruck 40 Tastendruck 33 Tastendruck 33 Tastendruck 33 Tastendruck 39 Tastenfreigabe 33 Tastendruck 39 Taste Drücken Sie die 66-Taste. Drücken Sie die Taste 31.  

Jeder Prozess, der ausgeführt wird, während Sie das Kennwort an der Eingabeaufforderung oder am Terminal eines anderen Prozesses abhören und dann sudo selbst aufrufen können (dies folgt direkt aus der Meldung "Keine Notwendigkeit, Sie zu schützen" Sie "Denkweise), daher ist es nutzlos, die Sicherheit der Kennwortabfragen zu erhöhen, es sei denn, wir ändern das Sicherheitsmodell grundlegend und schreiben alle möglichen Dinge massiv neu.

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

Wayland

Wayland ist ein neues Protokoll, das darauf abzielt X11 ersetzen. 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 des externen IPC miteinander kommunizieren, indem sie den Compositor durchlaufen, der sie alle steuert. Dies behebt jedoch nicht das zugrunde liegende Problem und verlagert einfach das Vertrauensbedürfnis auf den Compositor.

Virtualisierung und Container

Wenn Sie mit Cloud-Technologien arbeiten, müssen Sie Ich springe wahrscheinlich auf und ab und sage "Docker ist die Antwort !!". In der Tat, Brownie Punkte 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" unterteilt sind, z B. Arbeit, Banking, Surfen im Internet.

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

Fazit: Aus Sicht eines Endbenutzers ist es nicht unangemessen zu erwarten, dass sich Linux so verhält Genau 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 entworfen 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 Methode.

In diesem Fall besteht der wichtige Unterschied darin, dass Linux auf niedriger Ebene als Mehrbenutzerserver konzipiert ist und die Entscheidung trifft, einen Benutzer während Windows nicht vor sich selbst zu schützen ist als Einzelbenutzer-Workstation konzipiert, sodass Sie innerhalb einer Anmeldesitzung über prozessübergreifende Schutzfunktionen verfügen müssen. Es ist auch wichtig, dass unter Windows die GUI Teil des Betriebssystems ist, während unter Linux die GUI nur eine andere Anwendung auf Benutzerebene ist.

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 Kennwort fragt?

Schnelle Antwort: Nein.

Aus Sicht des Benutzers gibt es keine Garantie dafür, dass die Eingabeaufforderung vom Betriebssystem stammt. Es kann sich um jedes 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 ein Schadprogramm aktiviert ist Auf dem Computer 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).

Andernfalls wird nicht nach Passwörtern gefragt . Dieser Dialog ist für nicht technische Benutzer praktisch. Wenn Sie Sicherheitsbedenken oder einen Administrator oder ähnliches haben, 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).

Durch regelmäßige Aufforderung des Benutzers zur Eingabe des Kennworts lehrt das System den Benutzer, dass es selbstverständlich ist, sein Systemkennwort zu geben, wenn eine Anwendung danach fragt.

Wie beschrieben, fragen Sie 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 gepflegt und getestet und dann ausgerollt werden? oder in die andere Richtung Dinge wie Ansible?
Völlig unabhängig von der Sicherheit können Updates zu Problemen führen. Deshalb.

Ja. Das ist unsicher!

Ich persönlich brich diesen Dialog immer ab. Nicht weil es gefälscht 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.

Im Gegensatz zu Ihrer Meinung sind die (modernen) Windows- und Ubuntu-Methoden zum Umgang mit Berechtigungsstufen und zur Erhöhung von Berechtigungen ziemlich ähnlich. Der Grund ist sicherlich, dass die Betriebssysteme beide Mehrbenutzersysteme mit ähnlichen Anwendungsfällen sind, die mit ähnlichen Problemen konfrontiert sind.

Beide Betriebssysteme schränken die Möglichkeiten eines normalen Benutzers ein (natürlich durch Ausführen von Programmen). Ein Benutzer kann seine eigenen Daten zerstören, im Idealfall jedoch nicht die anderer Personen (es sei denn, sie haben sie geteilt), und kann das System im Idealfall nicht gefährden oder beschädigen. Zum Lesen und Schreiben von Systemdaten benötigt ein Programm Administratorrechte (Root) auf beiden Betriebssystemen, über die normalerweise nur vom Administrator / Root gestartete Programme verfügen.

Um dies zu vereinfachen, bieten beide Betriebssysteme dem Standardbenutzer die Möglichkeit, einzelne Programme mit "erhöhten Berechtigungen" über sudo bzw. UAC auszuführen. Beide Betriebssystem-GUIs starten einen Dialog, um dem Benutzer die Möglichkeit zu geben, zu verhindern, dass Programme als Administrator / Root ausgeführt werden. Beide Systeme haben auch die Vorstellung von Benutzern, die überhaupt keine privilegierten Programme ausführen dürfen.

Im Ubuntu-Dialogfeld werden Sie nach einem Kennwort gefragt. Das Windows-UAC-Dialogfeld funktioniert nicht. (Sie scheinen zu glauben, dass ein Programm spezielle Berechtigungen benötigt, um diesen Dialog anzuzeigen. Dies ist nicht der Fall. Das Programm fragt nach ihnen mit dem Dialog. Wenn jemand den Dialog vortäuscht, erhält er Ihren (Benutzer) Passwort, das für ein Programm, das bereits als dieser Benutzer ausgeführt wird, kein Gewinn ist.)

Unter dem Strich kann ein Schadprogramm so tun, als ob es erhöhte Berechtigungen für etwas Nützliches benötigt, und den Dialog starten, aber Sobald sie diese erhalten haben, formatieren Sie die Festplatte. ^{1 sup> Dies gilt für beide Betriebssysteme. Da unter Windows normalerweise mehr Software von Drittanbietern installiert wird, ist die Wahrscheinlichkeit, ein solches Programm zu starten, wahrscheinlich höher als bei Ubuntu.}

Sie erwähnen, dass in Windows das UAC-Dialogfeld normalerweise das Ergebnis einer Benutzeraktion ist, beispielsweise der Installation eines Programms, während Ubuntu das Dialogfeld ohne ersichtlichen Grund startet. Ein Grund, den ich mir vorstellen kann, ist, dass Windows-Softwareupdates vom Betriebssystem initiiert werden, sodass sie bereits über erhöhte Berechtigungen verfügen. Vielleicht fragt Ubuntu vor der Installation.

Es wäre in der Tat schön, mehr Informationen zu haben als nur "Ich brauche Ihren Reisepass, Ihre Stiefel und Ihre Jacke." Ich habe hier kein Ubuntu-System zur Hand, aber auf der linken Seite des Dialogfelds wird eine Beschriftung "Details" angezeigt. Hast du nachgesehen, was gesagt wird? (Natürlich könnte ein Schadprogramm dort jeden Text fälschen, aber Sie können möglicherweise überprüfen, ob das angebliche Programm tatsächlich ausgeführt wird.)

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-besseren Zugriff.

Es gibt verschiedene, etwas weniger vollständige Möglichkeiten (XTerm hat 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 Linux und Windows-Sicherheitsmodelle besagen, 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.)

Schrecklicher, schrecklicher Mangel an Sicherheit. Als ich das Design von grafischem Sudo sah, biss ich in die Kugel und machte sudo passwd root gefolgt von apt-get remove sudo , dann ärgerte ich die Ubuntu-IRC-Leute wirklich, indem ich die Deinstallation befürwortete sudo.

Trotzdem ist das völlig unsicher. Auf dem Terminal war es ein bisschen in Ordnung (mehr noch, wenn die Muscheln schwächer waren, war es relativ unbekannt und Angriffe dagegen hatten sich nicht wirklich entwickelt), aber es ist jetzt ein eklatanter Schwachpunkt.

Ich werde lieber eine zweite X-Instanz starten Als root jetzt für weniger als einmal im Jahr muss ich ein grafisches Programm root geben. (Ich starte dazu X: 1 direkt und nicht startx, sodass nur die Zielanwendung in der X-Instanz von root ausgeführt wird.) Wenn Sie häufiger root benötigen, empfehle ich apt-get install ssh und ssh -X root @ localhost .