Hi Andreas, ich habe leider keine SuSE mehr um dir genauere Angaben machen zu können. On Mon, Feb 16, 2004 at 10:39:39AM +0100, Andreas Feile wrote:

Daniel Lord, Montag, 16. Februar 2004 10:22:

...

Bei SuSE lies sich das glaube ich auch über die Umgebungsvariable export WINDOWMANAGER=wmaker lösen (bei xdm/kdm keine gute Idee)

Warum ist die Idee nicht gut?

weil sie nicht oder nur umständlich funktioniert in Verbindung mit xdm/kdm

Indes: diese Konfiguration will ich dem User aufzwingen. Wenn die Variable in ~/.xinitrc steht, dann kann es der User selbst ändern. Und das will ich nicht.

keine weiteren WM zu installieren löst dieses Problem halbwegs.

...

...

Und 3.: kann ich dem xdm beibringen, einen bestimmten User automatisch einzuloggen?

Das willst du nicht wirklich *hoff*.

Würdest Du alle Benutzer eines Surfkiosk zwingen, sich mit gast/gast einzuloggen? Ich denke, das bringt keine Sicherheit, sondern nur Umstände. Oder sehe ich was falsch?

Surfkiosk, OK. Da ist der Login überflüssig. XDM und KDM sind es dort auch. Die User müssen/dürfen ihre GUI ja sowieso nicht verlassen. D.h. du musst dafür sorgen, dass sie nicht an eine shell kommen können. (menü und tastenkürzel) über z.B. keylaunch die Tastenkürzel <strg> <alt> (|<BS>|<ENTF>) etc. abfangen und das $HOME Verzeichnis so einrichten, dass der Kioskbenutzer nur lesen kann. Dann kannst auch die .xinitrc da belassen. Wenn der User im $HOME irgendwas verändern kann dann musst du noch X weitere Möglichkeiten beachten. Die Partitionen auf die der User rw zugreifen darf müssen ausserdem mit noexec,nosuid gemountet werden. Der Schutz ist allerdings recht zweifelhaft :\ Also besser keine schreibrechte. /me stellt fest das so ein Kiosk Horror ist. :) Und möchte nicht mit dir tauschen. Greetings Daniel -- Real Life ist wie Windows, man weiß nie, was als nächstes schief geht....

Hallo Andreas, On Mon, Feb 16, 2004 at 11:33:10AM +0100, Andreas Feile wrote:

Daniel Lord, Montag, 16. Februar 2004 11:22:

...

Surfkiosk, OK. Da ist der Login überflüssig. XDM und KDM sind es dort auch. Die User müssen/dürfen ihre GUI ja sowieso nicht verlassen.

Wie umgeht man denn einen xdm/kdm? Ich meine, wenn die Maschine in RL5 wechselt, wie krieg ich dann den Window-Manager mitsamt Browser hoch, ohne vorher xdm usw. durchlaufen zu haben?

in runlevel 3 booten. Dann entweder von Hand einloggen startx -- -nolisten tcp& exit alternativ (ungetestet) script in /etc/init.d das in der start) section ein sudo -u <user> startx -- -nolisten tcp& exit stehen hat. Den Browser schreibst du in die ~/.xinitrc vor das exec $WM z.B. epiphany & # das & ist wichtig.

...

D.h. du musst dafür sorgen, dass sie nicht an eine shell kommen können. (menü und tastenkürzel) über z.B. keylaunch die Tastenkürzel <strg> <alt> (|<BS>|<ENTF>) etc. abfangen

Was ist den keylaunch? Finde ich im Yast nicht als Paket, und mit key<tab><tab> kommt auch nix.

ein Programm das Tastaturkürzel verwaltet. Windowmaker hat sowas zwar schon drin ich weiss aber nicht mehr wie gut der konfigurierbar ist. Das Programm findest du, wie auch einen für deine Zwecke idealen Windowmanager auf www.oroborus.org

...

und das $HOME Verzeichnis so einrichten, dass der Kioskbenutzer nur lesen kann. Dann kannst auch die .xinitrc da belassen. Wenn der User im $HOME irgendwas verändern kann dann musst du noch X weitere Möglichkeiten beachten.

Ich hatte gedacht, das ~ rw zu lassen, und die Maschine des nächtens über einen cronjob zu rebooten, wobei das ~ gelöscht wird, und eine Kopie davon wieder eingespielt wird. So gehen jede Nacht alle Änderungen wieder verloren.

Das ist zwar möglich aber der User hat den ganzen Tag über Zeit eine Datei zu speichern und auszuführen die z.B. einen local root xploit enthält. Danach kannst du dann lange das $HOME ersetzen root hat der Benutzer trotzdem. Wenn er böse ist findest nach dem reboot auch dein System nicht wieder ;\

...

Die Partitionen auf die der User rw zugreifen darf müssen ausserdem mit noexec,nosuid gemountet werden. Der Schutz ist allerdings recht zweifelhaft :\ Also besser keine schreibrechte.

Wenn der User gar nix schreiben darf, wird dann der Browser überhaupt richtig funktionieren? Ich denke da an irgendwelche Lockfiles usw.

Der Browser darf keinen Cache haben. D.h es ist sinnvoll einen localen squid vorzuschalten. wie es mit lockfiles aussieht kann ich nicht sagen, das müsstest du ausprobieren. Mal schauen, vielleicht hab ich nachher mal ne halbe Stunde Lust sowas auszuprobieren.

...

/me stellt fest das so ein Kiosk Horror ist. :) Und möchte nicht mit dir tauschen.

whois -a /me? No whois server is known for this kind of object. *g*

Gemeint war meine Wenigkeit :) Greetings Daniel -- We spend money, increase administration, and take away functionality. Is it any wonder that security people are so misunderstood.

Hallo, Am Mon, 16 Feb 2004, Daniel Lord schrieb:

Das ist zwar möglich aber der User hat den ganzen Tag über Zeit eine Datei zu speichern und auszuführen die z.B. einen local root xploit enthält. Danach kannst du dann lange das $HOME ersetzen root hat der Benutzer trotzdem. Wenn er böse ist findest nach dem reboot auch dein System nicht wieder ;\

$HOME in ne ramdisk? Gegen lokale Exploits sollte man natuerlich auch was machen, alles fest in den Kernel bauen z.B. -dnh -- "The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place." -- Douglas Adams in Guardian, 25-Aug-95

Am Di, den 17.02.2004 schrieb Andreas Feile um 08:15:

Gestern habe ich übrigens festgestellt, daß ein home, das ro ist, gar nicht gemocht wird von den Browsern. Galeon, Opera und Mozilla mögen da überhaupt nicht mehr laufen. Also werde ich das ~ beschreibbar machen müssen.

Könntest doch einen Symlink von einem tmp-verzeichnis, das für den Benutzer sowieso auch beschreibbar ist, zum Mozilla-Home-Verzeichnis des Nutzers machen. Somit wär das _Home_-Verzeichnis noch immer ro, aber das Mozilla-Profil befindet sich rw in $TMP. $TMP lässt man dann bei jedem Reboot säubern, und gut is?

Am Di, den 17.02.2004 schrieb Andreas Feile um 13:08:

Frank Wehrsenger, Dienstag, 17. Februar 2004 12:53:

Könnt ich. Aber wieso könnte ich dann nicht gleich ~ bei jedem Reboot bzw. jede Nacht cronjob-mäßig säubern, und gut is auch? Dann spar ich mir irgendwelche symlinks, und mach das ~ ganz normal rw. Außerdem will ich ja nicht rebooten, sondern den ersten Kiosk mit ner Uptime von > 500 Tagen bauen ;)

Du kannst es natürlich ebenso per Cronjob ohne den Reboot säubern, aber den letzteren hattest du doch glaub ich mal ins spiel gebracht ;) Nun, es hätte imho den Vorteil, das ganze Home-Verzeichnis als ro in einer solchen Umgebung, daß die Benutzer weniger Unfug machen könnten sei es nun zumüllen oder ändern von Benutzerspezifischen Einstellungen.