☰

Wie kann verhindert werden, dass ein Sudo-Benutzer die Daten anderer Sudo-Benutzer sieht?

tag-icon • tag-icon linux python administrator sudo
Wie kann verhindert werden, dass ein Sudo-Benutzer die Daten anderer Sudo-Benutzer sieht?

Ich bin neu bei Linux (Ubuntu, falls das wichtig ist). In meiner Firma gibt es mehrere Sudo-Benutzer auf einem Rechner. Die Situation ist wie folgt:

  1. Jeder möchte Sudo-Benutzerrechte, weil er behauptet, während seiner Arbeit Python-Pakete installieren zu müssen (sie sind KI-Ingenieure).

  2. Jeder Benutzer speichert private RSA-Schlüssel in seinem Home-Ordner, um sie schnell auf GitHub zu ziehen/zu pushen.

Wenn also ein Sudo-Benutzer theoretisch auf Abwege gerät, kann er einfach die privaten Schlüssel aller stehlen, sie aufzwingen und den Quellcode abrufen, auf den er keinen Anspruch hat. Wie verhindere ich, dass das passiert?

Danke

Antwort1

Ich gebe Ihnen keine direkte Antwort auf Ihre Frage, da Sie eineXY-Problem. Dies ist Ihr zugrunde liegender,tatsächlichProblem:

Jeder möchte das Sudo-Benutzerprivileg, weil er behauptet, während seiner Arbeit Python-Pakete installieren zu müssen

Das Problem ist folgendes:niemand muss es verwenden sudo, um Python-Pakete zu installieren.Tatsächlich wird davon dringend abgeraten. Insbesondere wenn mehrere Personen dasselbe System verwenden, können Sie niemanden davon abhalten, an Paketen auf Systemebene herumzubasteln, die andere möglicherweise benötigen. Was ist, wenn es Versionskonflikte, schwerwiegende Änderungen in einigen Paketen usw. gibt?

Lösung 1 – Installationen auf Benutzerebene

Die wirkliche Lösung besteht darin, Python-Pakete auf Benutzerebene zu installieren. Das heißt, statt sudo pip install …:

pip install --user pandas

Dadurch wird das Paket im Home-Verzeichnis des jeweiligen Benutzers installiert und die Systempaketbibliothek unverändert gelassen.

sudoIch kann es nicht genug betonen: Die Verwendung mit bringt nie etwas Gutes hervor pip.

Lösung 2 – Pipenv oder Poetry

Eine noch bessere Lösung besteht darin,mitpipenvoderpoetry, die eine virtuelle Umgebung für Pakete erstellen.

Die Pakete und Versionen können für verschiedene Projekte sogar unterschiedlich sein. Dies ist insbesondere dann wichtig, wenn ein Paket eine Zeit lang auf einer bestimmten Version bleiben muss (z. B. wenn es pandasdafür bekannt ist, seine API zu ändern; scipywenn es vor einiger Zeit einige gravierende Änderungen gegeben hat usw.).

Ich hätte Pipenv empfohlen, aber seit 2020 lässt die Wartung ziemlich zu wünschen übrig und es gibt seit Ewigkeiten keine Veröffentlichung mehr.

Um Poetry zu verwenden, installieren Sie es einfach auf Benutzerebene:

pip install --user poetry

Initialisieren Sie dann eine neue Umgebung für das aktuelle Projekt:

cd /path/to/project
poetry install pandas

Dadurch wird eine neue Poetry-Konfigurationsdatei erstellt, die die Anforderungen für das aktuelle Projekt angibt. Führen Sie sie aus, poetryum mehr zu erfahren, oder lesen Sie die Dokumentation.

Lösung 3 —pyenv

Der beste Weg, dies zu tun, wäre, die Benutzer ihre eigene Python-Version installieren zu lassen. Sie können verwendenpyenvum Installationen ganzer Python-Distributionen auf Benutzerebene zu erstellen. Auf diese Weise können Benutzer die Python-Version verwenden, mit der ihr Pipenv-Projekt initialisiert wurde, z. B. eine Zeit lang bei 3.7 bleiben, bis sie auf 3.8 aktualisieren möchten.

Dies ist insbesondere dann praktisch, wenn Sie nicht alle Pakete durch ein kleines Upgrade von Python auf Systemebene beschädigen möchten, falls dies jemals erforderlich sein sollte.

Fazit: Geben Sie normalen Benutzern keinen Sudo-Zugriff, wenn Sie ihn nicht benötigen. Lassen Sie sie ihren eigenen Benutzerbereich für die Installation von Python und/oder Python-Paketen verwenden.

Vorbehalt: Einige Python-Pakete benötigen möglicherweise bestimmte Bibliotheken, um erfolgreich erstellt zu werden. Sie können die Installation dieser Bibliotheken auf Systemebene nicht wirklich vermeiden, aber in solchen seltenen Fällen ist ein Administrator möglicherweise bereit, die sudo apt install …benötigte Bibliothek bereitzustellen.

Antwort2

Vermutlich stellen die Python-Entwickler per Remote-Zugriff auf diesen Computer eine Verbindung her, sshanstatt sich direkt über die Konsole anzumelden.

In diesem Fall dann ihre privaten Schlüsselsollte nichtaus genau diesem Grund überhaupt nicht auf der gemeinsam genutzten Maschine sein. Stattdessen sollten sie ssh-agentauf ihren lokalen Maschinen laufen und sich mit der gemeinsam genutzten Maschine verbinden, indem sie verwenden ssh -A(oder ForwardAgent yesfür diesen Host in festlegen ~/.ssh/config) und die privaten Schlüssel nur auf ihren lokalen Maschinen behalten. Die Verwendung von ssh-agentund Agent-Weiterleitung bewirkt, dass die Remote-Maschine (gemeinsam genutzte Maschine) Authentifizierungsanforderungen (z. B. von GitHub) sicher zurück an die ssh-agentlokale Maschine des Benutzers weiterleitet, wo die RSA-Authentifizierung durchgeführt wird, ohne dass der private Schlüssel des Benutzers jemals einem anderen Host als seiner lokalen Maschine offengelegt werden muss.

(Wenn auf dem lokalen Computer Windows und keine Linux-/Unix-Variante läuft, sollte der Windows-SSH-Client trotzdem in irgendeiner Form eine SSH-Agent-Weiterleitung bereitstellen, aber ich weiß nicht, wie darauf zugegriffen werden kann. Weitere Einzelheiten finden Sie in Ihrer Dokumentation.)

Antwort3

Die Lösung wäre, den Python-Entwicklern nur die sudo-Berechtigung für die Befehle zu erteilen, die sie tatsächlich benötigen. Die zulässigen Befehle werden vollständig mit Argumenten angegeben, Platzhalter sind möglich.

Das Folgende ist eine Antwort aus dem Unix Stackexchange-Beitrag
So führen Sie einen SSH-Befehl (einen Sudo-Befehl) aus der Ferne ohne Kennwort aus.

Sie können sudo anweisen, das Kennwort für einige Befehle zu überspringen.

zB in/etc/sudoers

archemar  ALL = (www-data) NOPASSWD: /bin/rm -rf /var/www/log/upload.*

dies erlaubt mir,

sudo -u www-data /bin/rm -rf /var/www/log/upload.*

als Archemar ohne Passwort.

Beachten Sie, dass

sudo -u www-data rm -rf /var/www/log/upload.*

funktioniert nicht (es wird nach einem Passwort gefragt), da es rmsich von unterscheidet /bin/rm.

Bearbeiten Sie unbedingt /etc/sudoersmit visudodem Befehl.

Wenn Sie das fortgeschrittene Niveau erreicht haben, möchten Sie vielleicht Ihre eigenen sudoDateien im Format haben /etc/sudoers.d.

verwandte Informationen