X Autorität Bypass

Ich versuche, eine Anwendung zu schreiben, die als Daemon läuft und überwacht läuft X-Sitzungen. Im Moment habe ich Schwierigkeiten, die Dokumentation in Bezug auf das X-Sicherheitsmodell zu finden. Insbesondere versuche ich Verbindung zu laufenden X-Displays von meinem Daemon-Prozess. Aufruf XOpenDisplay(dispName) funktioniert nicht, ich denke, weil mein Prozess keine Berechtigung zum Herstellen einer Verbindung zu diesem Display hat. Nach ein bisschen Forschung, es sieht aus wie ich etwas mit xauth tun muss.X Autorität Bypass

In meiner Testumgebung wird der X-Server wie folgt begonnen: mit

#ffff##: MIT-MAGIC-COOKIE-1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

indem Sie einen Eintrag zu ~/.Xauthority:

/usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-QBEVDj

Diese Datei einen einzigen Eintrag enthält, die wie folgt aussieht der gleiche Hex-Schlüssel, kann ich Verbindung mit dem X-Server. Dies ist jedoch schwierig, da ich programmatisch finden Sie die Auth-Datei der X-Server verwendet wird (die Speicherort, von dem ich denke, wird von Distro zu Distro und wahrscheinlich von einem Start zum nächsten ändern), dann abfragen, Schreiben Sie dann eine neue Auth-Datei. Wenn der Prozess als Daemon läuft, hat er möglicherweise kein Home-Verzeichnis. Woher weiß ich also, wo ich die neuen Einträge schreiben soll?

Idealerweise, was ich suche, ist ein Weg, um die Notwendigkeit zu umgehen, die xauth Plätzchen in ~/.Xauthority oder sogar zu wissen, was das Cookie bei alle ist zu haben. Ich weiß, dass das unwahrscheinlich ist - was nützt ein Sicherheitsmodell , wenn es leicht überbrückt wird? aber ich hoffe, dass jemand auf dieser Liste ein paar gute Ideen haben kann. Gibt es eine Möglichkeit zu spezifizieren, dass mein Prozess privilegiert ist und somit automatisch Zugang zu jedem Display auf dem lokalen Rechner erhalten sollte?

Quelle

2009-08-19 Thomi

Ich entdeckte dieses Q bei der Lösung eines ähnlichen Problems und entdeckte in einem Systemcode eine Möglichkeit, die .xauthority-Datei zu finden, mit der die X-Anzeige initialisiert wurde, und machte einen Code, der hilfreich sein könnte: http : //blog.fox.geek.nz/2012/10/grunting-root-access-to-all-xorg-x11.html –

Auf einer grundlegenderen Ebene scheinen Sie nach Möglichkeiten zu suchen, Sicherheitsbarrieren zu umgehen, die waren aus guten Gründen dort hineingelegt. Ein weniger aufdringlicher Ansatz besteht darin, dass Ihre Benutzer einen Client ausführen, der über einen RPC-Mechanismus eine Verbindung zu Ihrem Daemon herstellt. Sie können es standardmäßig für alle Benutzer über die systemweiten X-Session-Hooks ausführen lassen, was es auch für einige Benutzer möglich macht - aber umständlich -, sich abzumelden. – tripleee

Sie müssen kein Basisverzeichnis verwenden, wenn Sie eine Umgebungsvariable XAUTHORITY angeben, die den Speicherort der Datei .Xauthority angibt. Lesen Sie die Manpage xauth.

Aber im Allgemeinen ist es schwer, die Auth-Datei zu finden, aus den Gründen, die Sie erwähnten; Auch dieser Ansatz "fishing for auth tokens" würde nur für lokale Anzeigen funktionieren.

In Bezug auf root (oder einen anderen Benutzer) Verbindung zu einem X-Server willy-nilly, müssten Sie wahrscheinlich den Quellcode, um dies zu tun, und Sie müssten etwas wie getpeereid zu erhalten die UID/GID des verbindenden Benutzers (dies funktioniert nur auf Unix-Domain-Sockets, was vermutlich der Typ ist, der für lokale Verbindungen verwendet wird).

Quelle

2009-08-19 12:14:28

Danke. Ich bin nur an lokalen Verbindungen interessiert. Ich bin in der Lage, lokale Konfigurationsdateien zu ändern, wenn ich meine Anwendung installiere, aber das Ändern des X-Server-Quellcodes und das Patchen des X-Servers bei der Installation kommt nicht in Frage. – Thomi

Xauth ist nicht der einzige Sicherheitsmechanismus für X

Es gibt auch eine andere (weniger sicher), die IP-basierte Authentifizierung nur führt (siehe xhost).

Wenn Sie also Ihren X-Server in diesen weniger sicheren Modus umschalten, vertraut er allen Verbindungen, die aus dem definierten Satz von IPs kommen.

Auf diese Weise müssen Sie nicht mit Xauthority überhaupt umgehen.

Quelle

2009-08-19 13:25:02 kazanaki

Danke. Ich kenne den xhost-basierten Authentifizierungsmechanismus. Vielleicht ist das der beste Weg zu gehen. Im Idealfall möchte ich den vorhandenen Authentifizierungsmechanismus überhaupt nicht ändern, da ich mich jetzt mit der Konfiguration des Benutzers herumärbe (können Sie sich den Aufruhr unter sicherheitsbewussten Benutzern vorstellen, wenn ich zum am wenigsten sicheren Authentifizierungsmechanismus wechsle, damit meine Anwendung ausgeführt werden kann) ?). – Thomi

Ich werde sagen, dass ich nie eine Anwendung ausführen würde, die mich dazu zwang, xauth auszuschalten, damit ich den ganzen "Aufruhr unter sicherheitsbewussten Benutzern" verstehe. –

Okay. Hier ist ein Kompromiss, der wahrscheinlich nicht dazu führt, dass Systemadministratoren dich töten wollen. Könnte sein. Verwenden Sie xhost und aktivieren Sie den Zugriff von einer privaten IP-Adresse (z. B. 127.1.2.3). Lassen Sie den Systemadministrator Firewall-Regeln einrichten, die nur Verbindungen zu 127.1.2.3 zulassen, wenn der Socket zu root (oder was auch immer) gehört. Erledigt. –

X Autorität Bypass

Antwort

Verwandte Themen