Restricted Shell - Best Practices

[Okapi]

Hi,

ich möchte auf meinem Shared-Hosting-Server den Kunden demnächst Shellzugang per SSH ermöglichen.

Ich überlege nun, ob ich die Login-Shell wrappe und chroote - Nachteil: Binaries und Libs sind mehrfach redundant in den Chroots vorhanden und müssen auch parallel gepflegt werden.

Dann habe ich etwas von "FreeBSD Jails" gehört - bin mir nicht sicher, inwiefern ich das gebrauchen kann bzw. habe Bedenken, dass ich mein Hosting-Control-Panel damit für alle Systeme außer Linux unbrauchbar mache für dieses Feature (schön wäre halt Interoperabilität).

Ansonsten soll es noch restriktive Shells geben - diese werden den User aber wiederum sicherlich nicht daran hindern, selbst eine Binary hochzuladen und auszuführen.

Genauso mit Scripts wie PHP, Ruby usw. - diese laufen per fcgi und suexec - erlauben es aber trotzdem, ein wenig "herumzuschnüffeln" (wenn auch nur oberflächlich).

Ich überlege nun, was am besten ist. Sofern FreeBSD-Jails praktikabel sind, wird es wohl das "Aus" für Linux & Co. bzgl. meines Panels werden. Würde mich über ein paar Denkanstöße und Erfahrungswerte freuen.

Okapi

 

[kazcor]

Ich kenne mich in der Materie zwar nicht so gut aus, aber hier ein paar Denkanstösse ...

Ansonsten soll es noch restriktive Shells geben - diese werden den User aber wiederum sicherlich nicht daran hindern, selbst eine Binary hochzuladen und auszuführen.

Du könntest die Partition/Platte der Benutzer einfach via noexec einbinden und schon sind hochgeladene Binaries kein Problem mehr.
Die restricted shell Funktionalität ist z.B. bei der Bash mit drin, so dass Du nur von Dir bestimmte Programme zum Ausführen freigibst. Der Benutzer kann (soweit ich weiß) sein Home auch nicht verlassen - das kann gut so sein oder unpraktisch, wenn er dann doch an bestimmte Daten kommen soll. Die Verzeichnisse mit solchen Daten könnte man dann allerdings via mount_nullfs im Home transparent einbinden.

Ansonsten pflegst Du theoretisch bei jails natürlich auch redundant je ein weiteres System mit - allerdings gibt es Ansätze wie ezjail, bei welchem ein zugrundeliegendes Basissystem einfach mehrfach verlinkt wird und auf diese Weise ein update recht einfach zu handhaben ist. Davon unabhängig kann jedes Jail seinen eigenen Satz von Paketen mit sich führen, die dann optimalerweise zentral via tinderbox verwaltet werden.

Das ist jetzt etwas hingeworfen, aber mit den entsprechenden Stichwörtern kannst Du Dich schonmal weiter schlau machen

 

[Okapi]

Vielen Dank schon mal!

Ich muß schauen, ob das mit der User-Partition und den suexec-Scripts dann funktioniert. Müsste aber eigentlich, oder? Die jeweiligen Interpreter (Ruby, PHP usw.) liegen ja woanders, d.h. die Scripts werden im Kernel-Kontext gar nicht ausgeführt.

mount_nullfs sagt mir bisher nichts - klingt aber nach lesenswerter Information

Ein Chroot (gleich womit) klingt gegenüber der Möglichkeit einer restricted bash eher kompliziert, daher schaue ich mal, inwiefern ich das über eine noexec-Partition und eine restricted Shell lösen kann.

Mittels einfacher Rechtevergabe müsste ich es ja auch hinbekommen, dass ein User nicht /usr/local/var/mysql, /home, /var/log/apache2 usw. auslesen kann, um die "Nachbarkunden" zu erfahren.
Prinzipiell geht es ja um Datensicherheit der Nutzer unter sich bei diesem Thema - das System an sich hat bis auf ohnehin geschützte Daten keine kritischen Informationen.
Ich möchte halt vermeiden, dass jemand mit einem rekursiven Listing sich ein Inventar der vorhandenen Kundenordner bastelt - auch wenn er deren Dateiinhalte nicht lesen kann.