Was ist die Problemumgehung von 'ptrace_scope' für Wine-Programme und gibt es Risiken?


37

Um bestimmte Windows-Programme in WINE auszuführen, müssen Sie diese Problemumgehung ausführen:

echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope

Laut den Support-Websites liegt dies an einem Fehler im Ubuntu-Kernel, der verhindert, dass ptrace und WINE gut zusammenspielen.

Mit dem obigen Befehl setzen Sie den ptrace auf 0, was nach meinen Recherchen (frag mich nicht, auf welchen Websites ich viele davon gesehen habe) mit den Interaktionen zwischen Programmen zu tun hat. Die Einstellung 0 ist toleranter als die Einstellung 1.

Ich muss davon ausgehen, dass es einen guten Grund gab, warum Ubuntu ptrace = 1 haben wollte. Dies führt mich zurück zur Kurzform der Frage.

Besteht das Risiko, ptrace = 0 zu setzen? Geringere Sicherheit? Probleme beim Debuggen? irgendwelche anderen, an die ich nicht gedacht habe ???

PS: Wenn Sie dies lesen und sich fragen, was der Fehler verursacht, werden die Windows-Programme überhaupt nicht geöffnet. Im Systemmonitor werden viele Instanzen des Programms angezeigt, die versuchen, sich zu öffnen, und schließlich werden sie alle beendet, und wenn Sie das Programm ausführen Für das Terminal erhalten Sie eine Fehlermeldung, die Sie darüber informiert, dass die maximale Anzahl von Programminstanzen erreicht wurde.


Hier ist eine Beschreibung einer PlayOnLinux-Popup-Fehlermeldung, die die Installation von .Net 4.5 abbricht, sofern ptrace_scope nicht auf 0 gesetzt ist: playonlinux.com/en/…
pabouk

Antworten:


41

Kurze Antwort: Noch keine praktische Gefahr, aber zum besseren Verständnis weiterlesen ...


Was ist das überhaupt ?

Dies liegt an einem Fehler im Ubuntu-Kernel, der verhindert, dass ptrace und WINE gut zusammenspielen.

  • Nein, ptrace-Schutz ist eine bewusste Kernel-Sicherheitsmaßnahme, die erstmals um Ubuntu 10.10 eingeführt wurde. Es ist kein Fehler und wird daher nicht "behoben".

  • In einfachen Worten, der Standardwert ptrace_scopevon verhindert 1, dass ein Prozess einen anderen überprüft und ändert, es sei denn, der zweite Prozess (untergeordnet) wurde vom ersten Prozess (übergeordnet) gestartet.

  • Dies kann bei einigen Programmen unter Wine zu Problemen führen, da wineserverdiese Programme über "Windows-Dienste" verfügen.

Was sind die Risiken bei der Einstellung ptrace_scopeauf 0?

  • Dadurch wird das alte Verhalten wiederhergestellt, bei dem ein Prozess einen anderen Prozess "verfolgen" kann, selbst wenn keine Eltern-Kind-Beziehung besteht.

  • Theoretisch kann ein Teil der Malware dies nutzen, um Ihnen / Ihrem Computer Schaden zuzufügen. zB kann es sich an Firefox anhängen und alle Ihre URLs / Passwörter usw. protokollieren. In der Praxis ist dies äußerst unwahrscheinlich, es sei denn, Sie installieren blind Binär-Debs von zufälligen Sites usw.

  • Soweit das Debuggen geht, die 0sind Einstellungen in der Tat erforderlich , für gdb, straceetc. zu Nicht-Kinder zu befestigen , wenn Sie sie mit erhöhten Rechten (sudo) ausführen.

Was sind die Probleme mit der Problemumgehung?

  • Die Problemumgehung ist etwas problematisch, da ptrace_scopees sich um einen globalen Wert handelt und 0alle Prozesse auf Ihrem System von der Einschränkung ausgenommen sind, die keine untergeordneten Prozesse sind.
  • Wenn Sie die Problemumgehung verwenden, fügen Sie sie in ein einfaches Bash-Skript ein, das sie aktiviert, Ihr Windows-Programm ausführt und beim Beenden deaktiviert (auf 1 gesetzt).
    • Machen Sie es NICHT für die ptrace_scopeWelt beschreibbar (666), wie es der Forumsbeitrag empfiehlt - das ist ein riesiges Sicherheitsrisiko, da es jetzt von jedem Prozess nach Belieben geändert werden kann!

Gibt es eine bessere Lösung?

  • Eine bessere, sicherere Lösung, bei der ptrace_scope nicht wiederholt geändert werden muss, besteht darin , Wineserver-ptrace-Funktionen zuzuweisen .

    • In einem Terminal:

      sudo apt-get installiere libcap2-bin 
      sudo setcap cap_sys_ptrace = eip / usr / bin / wineserver
      sudo setcap cap_sys_ptrace = eip / usr / bin / wine-preloader
      
    • Dies befreit den Weinserver und den Wine-Preloader von der Nicht-Kind-Ptrace-Einschränkung und ermöglicht es ihnen, jeden Prozess zu verfolgen.

    • Dies muss nur einmal durchgeführt werden und ist sicherer, da diese Binärdateien in der Regel von einer vertrauenswürdigen Quelle stammen - den offiziellen Repositorys oder dem offiziellen Wine PPA -, sodass sie keine Malware darstellen.

Wenn Sie Crossover verwenden

Installieren Sie libcap2:

sudo apt-get install libcap2-bin;

Fügen Sie dann eine Ausnahme für Crossover hinzu:

sudo setcap cap_sys_ptrace = eip / opt / cxoffice / bin / wineserver;
sudo setcap cap_sys_ptrace = eip / opt / cxoffice / bin / wine-preloader;

Fügen Sie abschließend die Bibliotheken zu ld.so.conf hinzu (oder es wird "Fehler beim Laden der gemeinsam genutzten Bibliotheken angezeigt: libwine.so.1: Datei mit gemeinsam genutzten Objekten kann nicht geöffnet werden: Keine solche Datei oder solches Verzeichnis"):

echo / opt / cxoffice / lib / | sudo tee /etc/ld.so.conf.d/crossover.conf
sudo / sbin / ldconfig

Ich denke, es wird ein Fehler genannt, weil ptrace in 10.10 einwandfrei funktionierte, nachdem Wine gepatcht wurde, um ihn zu unterstützen. Es hat mit 10.10.11.10 funktioniert, ist aber in 12.04 zurückgegangen.
TrailRider

Vielen Dank für die Annahme @ TrailRider; Ich bezog mich auf Ihre Aussage, dass "es ein Fehler im Kernel ist " (was es nicht ist); Es ist sicherlich ein Bug-of-Sorts für Wine und sollte überfrachtet werden :) Die Dinge im Kernel ändern sich sicherlich manchmal, normalerweise zum Besseren, und es bleibt der betroffenen Software überlassen, sich selbst zu reparieren, anstatt Linus zu sagen "yo man, geh und mach dich wieder gesund ": P
ish

Ich verstehe, was Sie hier sagen, und stimme zu, ich habe nur gesagt, dass es ein Fehler im Kernel war, da es von mehreren Support-Websites sowie Codeweavers als Kernel-Fehler bezeichnet wurde. Hier ist Codewebers Seite drauf. codeweavers.com/support/wiki/linux/faq/ubuntu1204
TrailRider

2
Ich habe den globalen ptrace auf 0 gesetzt und nach ein paar Sekunden wird die Anwendung wieder auf 1 gesetzt. setcap ist VIEL sicherer und nicht ärgerlich, weil es die ganze Zeit sudo muss .. thx vm!
Aquarius Power

@izx: Danke für diese Antwort. Es wäre interessant, Informationen darüber hinzuzufügen, worauf sich "eip" bezieht (hier erklärt: andy-pearce.com/blog/posts/2013/Mar/file-capabilities-in-linux ). Außerdem habe ich vorgeschlagen, diese Methode in den Reptyr-Dokumenten zu empfehlen, in denen der Autor darauf antwortete, dass es sich möglicherweise um ein Sicherheitsproblem handelt: github.com/nelhage/reptyr/pull/27#issuecomment-29486673 - es wäre großartig, wenn Sie dies erläutern könnten auf diesem.
bläulich

4

Im ubuntuforums.org habe ich eine Antwort mit folgendem Link bekommen

https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection

Hier ist die Paste aus dem Link (mit meiner Hervorhebung hinzugefügt)

Da Linux immer beliebter wird, wird es ein wachsendes Ziel für Malware. Eine besonders besorgniserregende Schwäche der Linux-Prozessschnittstellen besteht darin, dass ein einzelner Benutzer den Arbeitsspeicher und den Betriebszustand eines beliebigen Prozesses untersuchen kann. Wenn beispielsweise eine Anwendung (z. B. Firefox) kompromittiert wurde, kann ein Angreifer eine Verbindung zu anderen laufenden Prozessen (z. B. gpg-agent) herstellen, um zusätzliche Anmeldeinformationen zu extrahieren und den Umfang seines Angriffs weiter zu erweitern.

Dies ist kein theoretisches Problem. SSH-Session-Hijacking und sogar beliebige Code-Injection sind vollständig möglich, wenn ptrace normal erlaubt ist .

Für eine Lösung verwenden einige Anwendungen prctl (), um einen solchen ptrace-Anhang (z. B. ssh-agent) spezifisch zu verbieten. Eine allgemeinere Lösung besteht darin, ptrace nur direkt von einem übergeordneten zu einem untergeordneten Prozess zuzulassen (dh Direct GDB und Strace funktionieren immer noch) oder als Root-Benutzer (dh GDB BIN PID und Strace -p PID funktionieren immer noch als Root).

Dieses Verhalten wird über den Wert / proc / sys / kernel / yama / ptrace_scope sysctl gesteuert. Die Standardeinstellung ist "1", um nicht untergeordnete Spuren zu blockieren. Mit dem Wert "0" wird das zuvor eher zulässige Verhalten wiederhergestellt, das möglicherweise für einige Entwicklungssysteme und Server mit nur Administratorkonten besser geeignet ist. Die Verwendung von "sudo" kann auch vorübergehend Ptrace-Berechtigungen über die CAP_SYS_PTRACE-Funktion gewähren, obwohl diese Methode das Ptrace eines beliebigen Prozesses ermöglicht.

Ich denke, die kurze Antwort wäre, dass es weniger sicher ist, aber die Wahrscheinlichkeit, dass ein PC unter solchen Angriffen steht, ist ziemlich gering.


1

UPDATE Die obigen Anweisungen:

sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wineserver;
sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wine-preloader;

funktioniert ab dem 15.09.2008 unter Ubuntu 18.04.1 und PlayOnLinux v.4.2.12 nicht, wenn die neueste stabile Version Wine v.3.0.1 libcap2 bereits installiert wurde.

Die Fehlermeldung in Gnome Terminal lautet wie folgt:

Failed to set capabilities on file `/usr/bin/wineserver' (Invalid argument)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file

Ich bin mir nicht sicher, was das bedeutet ... aber ich dachte, ich würde es für jeden herausbringen, um es zu interpretieren und vielleicht eine neue, praktikable Lösung zu finden.

Vielen Dank.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.