Silc&News-only user?

[kong]

Hallo,
bin gerade dabei einen kleinen stand-alone News & Silc Server einzurichten. Nun würde ich den Zugang gerne so regeln, dass man sich auf einer Webseite einen Account aussuchen kann, den dann verwenden oder auch wieder zurückgeben. So, dass also einerseits nur von mir eingerichtete Accounts überhaupt Zugang haben, andererseits jeder der will (begrenzt durch die Anzahl der von mir eingerichteten Accounts) ohne persönliche Daten übers Netz schieben oder irgendwo speichern zu müssen Zugang bekommt. Bei meinen OpenBSD-Anfängerrecherchen bin ich in der FAQ auf openbsd.org zu der Frage wie man einen ftp-only Account einrichtet auf folgendes gestoßen:
"There are a few ways to do this, but a very common way to do such is to add "/usr/bin/false" into "/etc/shells". Then when you set a users shell to "/usr/bin/false", they will not be able log in interactively, but will be able to use ftp capabilities."
Jetzt die Frage: Wie stehen dazu die übrigen Services, die der Rechner anbietet? Bei ssh ist es ja so, dass die ssh-shell normalerweise nach dem Login die shell des Users startet. Ein User ohne shell bekommt so also keine, die ssh-shell akzeptiert aber Komandos ("accepts commands" laut Doku) - ist das ein Sicherheitsrisiko? Außerdem gibt es ja da auch noch sftp, das dürfte doch genauso wie ftp auch ohne Usershell gehen. Muß ich so einen User ohne shell von der Benutzung von ssh explizit ausschließen? Stimmt meine Annahme, dass so ein User aber im Prinzip nichts daran hindert den silc- oder newsserver zu benutzen, da die ja nicht von der Shell des Users abhängen?

 

[oenone]

wozu brauchst du für News oder Silc user-accounts auf dem System?

 

[kong]

wozu brauchst du für News oder Silc user-accounts auf dem System?

Brauchen ist übertrieben. Die Idee geht so: Ich lasse keine anonymen oder multiplen Logins zu um die damit verbundenen Sicherheitssorgen nicht zu haben. So kann ich meinen Usern aber keine Anonymität gewähren, außer ich richte ein vom Internet aus manipulierbares Account-erzeugungs und -verwaltungssystem ein, was fast schon wieder wie anonyme/multiple Accounts ist. Dann lese ich diesen Satz in der OpenBSD-FAQ und finde diese Herangehensweise äußerst elegant. Ich mache user, deren Namen und Passwörter nichts nützen - keine shell. Dann sage ich den Servern sie sollen nur mit Usern des Systems reden, sonst mit niemandem. Soweit die Server laufen stellen sie also quasi die shell für die betroffenen User da. Jetzt nur noch den Servern, die die öffentlichen User nicht benutzen können sollen sagen sie sollen z.B. die zugehörige group ausschließen - was gar nicht viel betrifft, halt ssh z.B., wo der Ausschluß jedoch ziemlich leicht und sicher zu sein scheint. So hätte ich ein sehr sicheres, auch weil nur eines - nämlich das des Systems selbst - Loginsystem und zugleich Anonymität der User.
Die Frage bleibt - bzw. ist: Enthält diese Herangehensweise einen Denkfehler oder übersehe ich dabei etwas, wodurch eine derartige Konfiguration den Server zur leichten Beute für jeden Interessierten machen würde?

 

[oenone]

meine Frage war eine andere... Wozu brauchst du System-User, wenn sowohl silc- als auch news-server keine brauchen?

oder meintest du mit "server" in wirklichkeit "client" und willst leuten ermöglichen, einzuloggen und einen slic- bzw news-client zu starten?

auf bald
oenone

 

[kong]

Ich meine nicht Client statt Server, sondern ich meine schon INN und SILC Server. Mir ist schon bekannt das beide auch eine vom System getrennte eigene user-Verwaltung unterstützen können. Und wie gesagt: brauchen tue ich das deswegen ja auch gar nicht wirklich, ich überlege nur ob es nicht eine sehr sichere Methode wäre einerseits Userauthentifizierung zu betreiben, andererseits die Anonymität der User zu wahren. Warum die Arbeit, die Systemressourcen und die Sicherheitslücken weiterer Userlisten irgendwo, wenn es gar keine Gefahr durch öffentlich einsehbare Useraccounts gibt, die keine shell haben, außer den extra durch die dafür vorgesehenen Server zur Verfügung gestellten, auf die sie mit den entsprechenden Clients zugreifen können. Es ist doch sowiso die Logik des ganzen Berechtigungssystems in Unix, dass von root an abwärts immer weniger zur Verfügung steht, die shell, also die Schnittstelle mit dem User, von Keyboard mit root-Rechten abwärts sukzzessive weniger Funktionen zur Verfügung stellt. Der Einfall ist das einfach auf das Netz auszuweiten, bis zu der quasi sonst unbrauchbaren shell eines Newsclients irgendwo, von dem der Newsserver Verbindungen akzeptiert.

 

[oenone]

je nachdem wie die benutzerauthentifizierung der server mittels system-accounts funktioniert, kannst du einfach die shell auf /usr/bin/false setzen, dann ist ein login ins system nicht mehr möglich.

 

[kong]

je nachdem wie die benutzerauthentifizierung der server mittels system-accounts funktioniert, ...

Stimmt, genau das ist der Haken. Also, bevor jemand lange rumüberlegt und recherchiert, weil er das Sicherheitskonzept auch so elegant fände wie ich: Es geht wegen der Architektur der meisten Server nicht. Mit ssh und ftp geht es, nach meinen Recherchen aber sonst nicht; nichtmal mit sendmail und IMAP. Alle diese server beziehen sich wenn dann irgendwie anders auf die Systemuser als normale Programme, zu denen man den Zugang eigentlich ausreichend mit user- und group-Berechtigungen regeln kann (vorsicht mit setuids!) . Eigentlich kein Wunder: der Server läuft ja, bietet seinen Dienst an und muß dann entscheiden ob der Interessent berechtigt ist. Normale Programme laufen nicht und lassen sich von unberechtigten Usern auch nicht starten, d.h. das System macht die Berechtigung, nicht das Programm. Ssh und ftp sind Ausnahmen weil sie im Prinzip nur Tunnels zwischen Systemfunktionen darstellen.