Verhindern, dass Schüler Epoptes starten können

[Rüdiger Kupper]

Derzeit funktioniert unser Epoptes-Starter für alle Nutzer. Damit können sich auch Schüler gegenseitig ihre Bildschirminhalte anzeigen lassen, sich Botschaften schicken, ihre Bildschirme sperren oder ihre Clients Rauf- und Runterfahren.
Ich glaube nicht, dass wir das wollen ;-).

Eigentlich wird der Zugang über die Gruppenzugehörigkeit zur Gruppe eopotes geregelt. Bei uns werden Lehrer über /etc/security/group.conf dieser Gruppe zugewiesen, Epoptes schert sich aber irgendwie nicht darum (Vermutlich Bug in Epoptes.)
Wir starten Epoptes derzeit, indem sich der Nutzer als User epoptes passwortlos auf dem ltsp6 einloggt. Dieser Nutzer darf Epoptes starten. Das funktioniert aber derzeit auch für Schüler.

Vorschlag: Das epoptes-Binary einfach der Gruppe teachers übereignen und die Ausführungsrechte für "others" entfernen.

[Rüdiger Kupper]

Äh, nein, der Vorschlag funktioniert nicht, denn der Nutzer ist dann ja epoptes, nicht mehr der Lehrer :-).

Also muss verhindert werden, dass sich Schüler als epoptes einloggen. Wie ist das machbar?

[bau]

Äh, ich hatte im Hinterkopf, dass ich irgenwas im Starter gemacht hatte, so dass der nur für Lehrer ausführbar ist ???
Auf jeden Fall habe ich die zum einloggen ohne Passwort erforderliche SSH-Key-Datei der Gruppe Lehrer zugänglich gemacht und NICHT der Gruppe Schüler. Epoptes sollte doch ein Passwort haben, das keiner kennt - oder?
Wie können sich dann SuS noch anmelden?

[Rüdiger Kupper]

Replying to bau:

Äh, ich hatte im Hinterkopf, dass ich irgenwas im Starter gemacht hatte, so dass der nur für Lehrer ausführbar ist ???

Das war nur für den Client-Starter (der wird nur für Schüler ausgeführt, nicht für Lehrer). Im App-Starter gibt es keine Fallunterscheidung. Die könnte man natürlich hinmachen, doch das wäre nur eine halbherzige Lösung, denn dann kann ein Schüler die Anwendung natürlich trotzdem noch an der Kommandozeile starten.

Auf jeden Fall habe ich die zum einloggen ohne Passwort erforderliche SSH-Key-Datei der Gruppe Lehrer zugänglich gemacht und NICHT der Gruppe Schüler.

Das hatte ich auch überlegt, kann ich auch wieder so einrichten. Dann kann ein Schüler sich jedenfalls nicht mehr passwortlos zum Nutzer "epoptes" machen.

Epoptes sollte doch ein Passwort haben, das keiner kennt - oder?
Wie können sich dann SuS noch anmelden?

Nun ja, wir hatten damals ein denkbar einfaches Passwort gewählt (einmal raten reicht ;-) ). Das können wir in eins ändern, dass nur die Admins kennen. Dann wäre nur noch das Problem, dass das Passwort im Klartext in der lts.conf steht, um den Eopotes-Kiosk im LZ zu starten. Aber bis ein Schüler das dort findet...

[bau]

Jetzt mal eine ganz blöde Frage:
Ich hatte extra den Key für epoptes nur readable für die Gruppe Lehrer gemacht. Warum ist das nicht mehr so? Damit ist das Starten der epoptes-Umgebung auf allen LTSP-Servern unterbunden - außer auf ltsp6 - oder liege ich da falsch?

Wenn wir also das Passwort der epoptes ändern, dann ist dieser Zugang auch zu.
Lediglich ist noch zu überlegen, wie wir das Starten des epoptes für Jedermann auf ltsp6 verhindern.

Wegen des Epoptes-Kioks:
Es geht sicherheitstechnisch garnicht, dass das Passwort in einer World-Readable-Datei liegt, auf die SuS zugreifen können. Ich schlage vor: Umzug des Epoptes-Kiosk in das Lehrernetz. Dort darf das Passwort gerne in der LTS.conf stehen. Über die Firewall-Anbindung zum Schülernetz, die wir seit neuetem ja haben ist das auch kein Problem mehr.

Dann müsste das Loch doch gestopft sein - oder?

[Rüdiger Kupper]

Replying to bau:

Jetzt mal eine ganz blöde Frage:
Ich hatte extra den Key für epoptes nur readable für die Gruppe Lehrer gemacht. Warum ist das nicht mehr so?

Nach dem Neuaufsetzen der Server habe ich auch die Epoptes-Umgebung neu eingerichtet. Die Schlüsseldatei hat dabei erstmal die defaultrechte bekommen, ich ändere das wieder.

Damit ist das Starten der epoptes-Umgebung auf allen LTSP-Servern unterbunden - außer auf ltsp6 - oder liege ich da falsch?

Schüler können sich dann zumindest nicht mehr passwortlos als epoptes anmelden. Sie brauchen das Passwort des epoptes-Nutzers (siehe unten).

Wenn wir also das Passwort der epoptes ändern, dann ist dieser Zugang auch zu.
Lediglich ist noch zu überlegen, wie wir das Starten des epoptes für Jedermann auf ltsp6 verhindern.

Das geht ohnehin nicht, so weit ich weiß. Nur die Nutzer "epoptes" und "linadmin" können epoptes derzeit starten.

Wegen des Epoptes-Kioks:
Es geht sicherheitstechnisch garnicht, dass das Passwort in einer World-Readable-Datei liegt, auf die SuS zugreifen können. Ich schlage vor: Umzug des Epoptes-Kiosk in das Lehrernetz. Dort darf das Passwort gerne in der LTS.conf stehen. Über die Firewall-Anbindung zum Schülernetz, die wir seit neuetem ja haben ist das auch kein Problem mehr.

Gute Idee. Mit der Route ins Schülernetz hatte ich allerdings manchmal noch Probleme:
Von ltspl2 aus kann ich keine XMDCP-Verbindung zu den Schülerservern herstellen. Das sollte doch eigentlich klappen? Ich vermute, das hakelt noch irgend etwas.

Dann müsste das Loch doch gestopft sein - oder?

Richtig.

[Rüdiger Kupper]

Die Schlüsseldatei ist jetzt nur noch für die Gruppe teachers lesbar. Schüler werden nach dem Passwort für den Nutzer "epoptes" gefragt. Das ändere ich als nächstes.

[Rüdiger Kupper]

Das Passwort des Nutzers epoptes wurde durch ein zufällig generiertes ersetzt (Hinweis auf das gute Tool "apg", mit dem man sichere, zufällig Passwörter generieren kann.)
Das Passwort steht in der Datei auf dem paedml. Außerdem steht es noch im Klartext in der lts.conf des Servers, auf dem der Kiosk läuft.
Ein erster Test eben hat ergeben, dass der Kiosk problemlos auch im Lehrernetz stehen kann. Da ist zwar Netztechnisch etwas ungünstig (denn das Epoptes-Programm läuft ja dennoch auf ltsp6, dann eben über ssh. Damit wird die Grafik beim Betrachten der Bildschirme mehrfach über's Netz geschickt: Vom Server, auf dem der Schüler eingeloggt ist, per VNC auf ltsp6. Von dort ssh-Verschlüsselt nach ltspl2. Von dort nachmal über ssh an den Kiosk-Client), funktioniert aber.

TODO

• Epoptes-Kiosk im LZ ans Lehrernetz patchen
• Epoptes-Passwort in der lts.conf auf ltsp6 entfernen und auf ltspl2 eintragen.

Danach sollte der Kiosk auf ltspl2 laufen.

[Rüdiger Kupper]

Ich sehe gerade noch eine andere Möglichkeit:
In der Datei /etc/default/epoptes kann man die Gruppe eintragen, die epoptes starten darf. Wenn wir dort teachers eintragen, können alle Lehrer (und nur die) Epoptes starten, und zwar unter ihrem eigenen Namen.
Das ganze als-anderer-Nutzer-Einloggen kann dann entfallen, die Nutzer stellen einfach eine X-Verbindung unter ihrem eigenen Namen her, werden dafür nach ihrem Passwort gefragt, und nur wenn der Nutzer zur Gruppe teachers gehört, startet das Programm.

Für den Kiosk im LZ bräuchten wir dann natürlich einen Nutzer, der zur Gruppe teachers gehört, der automatisch eingeloggt wird. Damit müsste dessen Passwort dann wieder in der lts.conf stehen, also gleiches Problem.

[Rüdiger Kupper]

Andere Idee: Ich nehme an, die Datei lts.conf benötigt gar keine Weltleserechte. Wenn wir die wegnehmen, kann nur root die Datei lesen.
Das wäre vielleicht das einfachste, dann kann der Kiosk weiter auf ltsp6 laufen.

[bau]

Replying to kup:

Ich sehe gerade noch eine andere Möglichkeit:
In der Datei /etc/default/epoptes kann man die Gruppe eintragen, die epoptes starten darf. Wenn wir dort teachers eintragen, können alle Lehrer (und nur die) Epoptes starten, und zwar unter ihrem eigenen Namen.

Auf ltsp6 kein Problem

Das ganze als-anderer-Nutzer-Einloggen kann dann entfallen, die Nutzer stellen einfach eine X-Verbindung unter ihrem eigenen Namen her, werden dafür nach ihrem Passwort gefragt, und nur wenn der Nutzer zur Gruppe teachers gehört, startet das Programm.

auf den anderen ltsp keine gute Idee.
ich hatte extra die Geschichte mit dem passwortlosen Key gemacht, damit man als Lehrer nur auf den Starter klicken muss und schon erscheint das epoptes-Fenster.

[Rüdiger Kupper]

Replying to bau:

Das ganze als-anderer-Nutzer-Einloggen kann dann entfallen, die Nutzer stellen einfach eine X-Verbindung unter ihrem eigenen Namen her, werden dafür nach ihrem Passwort gefragt, und nur wenn der Nutzer zur Gruppe teachers gehört, startet das Programm.

auf den anderen ltsp keine gute Idee.
ich hatte extra die Geschichte mit dem passwortlosen Key gemacht, damit man als Lehrer nur auf den Starter klicken muss und schon erscheint das epoptes-Fenster.

Ich könnte mir vorstellen, dass sich die Kollegen vielleicht sogar sicherer fühlen, wenn sie erst nochmal ihr Passwort eingeben müssen ;-). Aber vielleicht auch nicht.

[Rüdiger Kupper]

Replying to kup:

Andere Idee: Ich nehme an, die Datei lts.conf benötigt gar keine Weltleserechte. Wenn wir die wegnehmen, kann nur root die Datei lesen.
Das wäre vielleicht das einfachste, dann kann der Kiosk weiter auf ltsp6 laufen.

Das hat sich leider nicht bestätigt: Der Client verbindet sich per TFTP als Nutzer "nobody" mit dem Server. Die Datei muss also für alle lesbar sein.

[Rüdiger Kupper]

Replying to kup:

TODO

• Epoptes-Kiosk im LZ ans Lehrernetz patchen
• Epoptes-Passwort in der lts.conf auf ltsp6 entfernen und auf ltspl2 eintragen.

Danach sollte der Kiosk auf ltspl2 laufen.

• Außerdem muss dann noch auf ltspl2 ein lokaler Nutzer eingerichtet werden, der automatisch eingeloggt wird und den passwortlosen ssh-Schlüssel besitzt.

[Rüdiger Kupper]

Ein radikal anderer Ansatz:
Wir nehmen als Kiosk einen Standalone-Rechner, keinen LtspClient. Auf dem kann irgend ein minimales lokal installiertes Linux laufen, es muss nur einen X-Server haben und sich über ssh als epoptes an ltsp6 einloggen.

[bau]

Perfekte Idee!
Die TC von der KSK haben eine kleine SSD eingebaut (ist wie ein USB-Stick).
Dort passt sicherlich ein DSL drauf, das sollte genügen - oder?

[Rüdiger Kupper]

Ja, sollte klappen. Wenn nicht, stecken wir eine der alten Platten in einen normalen Client.

[bau]

Die TC der KSK hatte ich für solcherlei Anwendungen schon im Auge, z.B. für digitale Türschilder z.B. am Doppelraum etc.

[Rüdiger Kupper]

Scheint derzeit nicht zu Problemen zu führen, Priorität runtergesetzt.

[jas]

Wie sieht es mit dem eigentlichen Ticket aus? gelöst? können SChüler epoptes noch starten?

[Rüdiger Kupper]

Update: Der Bug in Epoptes, der die durch pam_group zugewiesenen Gruppen ignorierte, wurde behoben (​launchpad:1338051). Im neuen 64-bit-Image der LM-Clients (christof) nutzen wir daher wie ursprünglich geplant diesen Weg, die Lehrer automatisch in die Gruppe epoptes aufzunehmen -- nicht aber die Schüler. Damit können nur Lehrer Epoptes starten.
Der "Login-Umweg" per ssh auf ltsp6 sollte damit hoffentlich überflüssig sein.