Python-Skript als Login-Shell, kann man das so machen?

[Ralph Aichinger]

Hallo alle, kann man folgendes machen:

https://pi.h5.or.at/mockturtle.txt

ist ein Python-Skript mittels des Moduls "cmd", das ein CLI
implementiert, quasi ohne sinnvolle Funktion einstweilen ;)

Ich habe dieses Skript in /etc/shells eingetragen, und als
Login-Shell eines Users "admin".

In /etc/ssh/sshd_config habe ich folgende Zeilen eingefügt:

Match User admin
X11Forwarding no
AllowTcpForwarding no
ForceCommand /usr/local/bin/turtle

(das Skript hab ich "turtle" genannt nach dem Beispielskript
von cmd, von dem es abgewandelt wurde)

Wer mag und IPv6 hat, kann es ausprobieren:

ssh -l admin probe.aisg.at
password: admin

Kann man sowas machen, ein Python-Skript als Login-Shell verwenden,
oder ist man da einen Schritt vor dem Gehackt werden? Irgendwelche
offensichtlichen Probleme mit meinem oben verlinkten Skript, vor
allem bezüglich Sicherheit?

TIA
/ralph

[Peter Heitzer]

Auf den ersten Blick kommt es mir sicher vor. Ich habe keine offensichtliche
Möglichkeit gefunden, auszubrechen. IMO wäre allerdings eine chroot
Umgebung bzgl. der Sicherheit noch günstiger.
https://www.tecmint.com/restrict-ssh-user-to-directory-using-chrooted-jail/
zeigt die notwendigen Schritte.
Da die Thematik nicht Python spezifisch ist, wäre eine Anfrage in einer
Linux Group evtl. zielführender.

--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

[Ralph Aichinger]

Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
> Auf den ersten Blick kommt es mir sicher vor. Ich habe keine offensichtliche
> Möglichkeit gefunden, auszubrechen. IMO wäre allerdings eine chroot
> Umgebung bzgl. der Sicherheit noch günstiger.
> https://www.tecmint.com/restrict-ssh-user-to-directory-using-chrooted-jail/
> zeigt die notwendigen Schritte.

Danke für deine Einschätzung!

> Da die Thematik nicht Python spezifisch ist, wäre eine Anfrage in einer
> Linux Group evtl. zielführender.

Ja, das stimmt natürlich.

/ralph

[Stefan Schwarzer]

On 2024-02-19 11:49, Ralph Aichinger wrote:
> https://pi.h5.or.at/mockturtle.txt
>
> ist ein Python-Skript mittels des Moduls "cmd", das ein CLI
> implementiert, quasi ohne sinnvolle Funktion einstweilen ;)

> [...]

Ich bin kein IT-Security-Experte, aber ein paar Gedanken dazu:

- Was passiert, wenn jemand eine Eingabezeile von einigen GB
schickt? Ich vermute mal, das würde auf einen DoS
hinauslaufen.

- Davon abgesehen, ist mir wie Peter auch nichts an deinem Code
aufgefallen, womit man aus deiner Shell ausbrechen könnte.

- Man kann das mit dem Chroot noch weiter treiben und den
Shell-Prozess in einen Podman- oder Docker-Container oder eine
VM einsperren. Auf der anderen Seite beziehungsweise
zusätzlich kannst du die Rechte des Users möglichst weitgehend
einschränken durch entsprechende Wahl der User-Id, Gruppen und
gegebenenfalls SELinux/AppArmor-Policy.

- Laut https://docs.python.org/3/library/cmd.html verwendet das
Modul für die Verarbeitungen der Eingabezeile die
readline-Bibliothek. Je nachdem, welche
Konfigurations-Einstellungen (z. B. in der `.inputrc` oder per
Default) gelten, könnte das die Angriffsfläche vergrößern.

Konkret ist mir gerade dieser Absatz aus der Doku aufgefallen:

> If the readline module is loaded, input will automatically
> inherit bash-like history-list editing (e.g. Control-P
> scrolls back to the last command, Control-N forward to the
> next one, Control-F moves the cursor to the right
> non-destructively, Control-B moves the cursor to the left
> non-destructively, etc.).

Das heißt, wenn sich mehrere Nutzer einen Account teilen,
verstehe ich das so, dass sie die History anderer Nutzer sehen
können. Keine Ahnung, ob das für deine Anwendung ein Problem ist.

Eventuell hat die Verwendung der Readline-Bibliothek noch
viel mehr Folgen.

- Auch wenn in deinem Code keine Sicherheitslücken zu erkennen
sind, ist mir nicht klar, ob bestimmte Funktionalität im
`cmd`-Modul, die bei "normaler" Nutzung kein Problem ist, in
deinem Anwendungs-Kontext doch ein Problem sein könnte.

Und selbst wenn du jetzt einen Audit des `cmd`-Moduls
durchführen würdest und das Modul für sicher befinden würdest,
könnte es sein, dass ein Update auf eine neue Python-Version
das ändert.

- Ob du den Ansatz mit der `cmd`-Shell trotz dieser
Randbedingungen verfolgen willst, hängt davon ab, welche
Angriffs-Szenarien du siehst und was die möglichen Folgen
wären.

Viele Grüße
Stefan

[Ralph Aichinger]

Stefan Schwarzer <sschw...@sschwarzer.net> wrote:
> - Was passiert, wenn jemand eine Eingabezeile von einigen GB
> schickt? Ich vermute mal, das würde auf einen DoS
> hinauslaufen.

Danke, das ist ein guter Einwand. Wenn man nur einen DoS-Angriff
auf das Restsystem (und nicht auf dieses Programm) verhindern will,
dann müßte man das eigentlich mit einem Speicherlimit ulimit o.ä.
zumindest mildern können. Danke!

> - Man kann das mit dem Chroot noch weiter treiben und den
> Shell-Prozess in einen Podman- oder Docker-Container oder eine
> VM einsperren. Auf der anderen Seite beziehungsweise
> zusätzlich kannst du die Rechte des Users möglichst weitgehend
> einschränken durch entsprechende Wahl der User-Id, Gruppen und
> gegebenenfalls SELinux/AppArmor-Policy.

Ja, danke, ich muß mir ansehen was davon Debian näher steht, ich
vermute AppArmor (das kenn ich auch von Ubuntu).

> - Laut https://docs.python.org/3/library/cmd.html verwendet das
> Modul für die Verarbeitungen der Eingabezeile die
> readline-Bibliothek. Je nachdem, welche
> Konfigurations-Einstellungen (z. B. in der `.inputrc` oder per
> Default) gelten, könnte das die Angriffsfläche vergrößern.
>
> Konkret ist mir gerade dieser Absatz aus der Doku aufgefallen:
>
> > If the readline module is loaded, input will automatically
> > inherit bash-like history-list editing (e.g. Control-P
> > scrolls back to the last command, Control-N forward to the
> > next one, Control-F moves the cursor to the right
> > non-destructively, Control-B moves the cursor to the left
> > non-destructively, etc.).
>
> Das heißt, wenn sich mehrere Nutzer einen Account teilen,
> verstehe ich das so, dass sie die History anderer Nutzer sehen
> können. Keine Ahnung, ob das für deine Anwendung ein Problem ist.

Danke, das muß ich mir ansehen.

> - Ob du den Ansatz mit der `cmd`-Shell trotz dieser
> Randbedingungen verfolgen willst, hängt davon ab, welche
> Angriffs-Szenarien du siehst und was die möglichen Folgen
> wären.

Sagen wir so, ich will keine Atomkraftwerke damit fernsteuern, eher
für harmlose IoT-Spielereien.

Danke für deine ausführlichen Anmerkungen, ich muss das erst mal
sacken lassen und Sachen ausprobieren (z.b. das gleichzeitig 2x
einloggen).

/ralph

[Peter Heitzer]

Ralph Aichinger <ra...@pi.h5.or.at> wrote:

>> - Ob du den Ansatz mit der `cmd`-Shell trotz dieser
>> Randbedingungen verfolgen willst, hängt davon ab, welche
>> Angriffs-Szenarien du siehst und was die möglichen Folgen
>> wären.

>Sagen wir so, ich will keine Atomkraftwerke damit fernsteuern, eher
>für harmlose IoT-Spielereien.

>Danke für deine ausführlichen Anmerkungen, ich muss das erst mal
>sacken lassen und Sachen ausprobieren (z.b. das gleichzeitig 2x
>einloggen).

>/ralph

Du hast in deiner Shell das Kommando "cal", das ich irrtümlicherweise
für das gleichnamige Programm, das einen Kalender anzeigt, hielt.
Es soll aber bei dir eine Kalibrierung von Sensoren anstossen. In diesem
Zusammenhang müsste ein Mehrfachlogin berücksichtigt werden, damit sich
die Kalibrierprozesse nicht in die Quere kommen. Eine einfache Dateisemaphore
sollte hier ausreichen.

[Ralph Aichinger]

Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
> Es soll aber bei dir eine Kalibrierung von Sensoren anstossen. In diesem
> Zusammenhang müsste ein Mehrfachlogin berücksichtigt werden, damit sich
> die Kalibrierprozesse nicht in die Quere kommen. Eine einfache Dateisemaphore
> sollte hier ausreichen.

Ich denke sowas werde ich gar nicht direkt in diesem Skript abhandeln,
sondern über ein REST-API entkoppelt in irgendwas anderes auslagern,
z.B. meine HomeAssistant-Instanz. Dadurch bekommt man vermutlich ein
"ich bin gerade beschäftigt mit Kalibrieren" oder sowas (als
Fehlermeldung/Status) ohne Aufwand realisiert.

Einen REST-Aufruf zu realisieren ist ja in Python zum Glück recht
einfach und schnell (sogar für einen weniger geübten Programmierer wie
mich) realisierbar.

/ralph
>