Re: User einsperren ohne jail

From: Marc Santhoff <M.Santhoff(at)web.de>
Date: Fri, 12 Feb 2010 12:29:39 +0100

Am Freitag, den 12.02.2010, 09:11 +0100 schrieb Polytropon:
> On Fri, 12 Feb 2010 08:47:45 +0100, Marc Santhoff <M.Santhoff(at)web.de> wrote:
> > Hmm, wo ich das so lese, könnte ichmir vorstellen $PATH auf $HOME/bin zu
> > beschränken (System immer zusätzlich, /bin, /usr/bin, ...) und dort nur
> > Links auf erlaubte Programme hinzulegen ... fragt sich, wo dann Lücken
> > bleiben, die ein frecher User sich zunutze machen könnte.
>
> Ganz einfach: Was in $PATH steht, kann der jeweilige User
> ja "normal" ohne Pfad aufrufen. Will er garstigerweise nun
> aber dd aufrufen und ist in ~/bin kein Link auf /bin/dd
> gesetzt, ruft er einfach "/bin/dd" explizit auf. Das
> funktioniert aber eben nur, wenn er weiß, wo welches
> Programm ist; "which" oder "whereis", ebenso wie "find"
> scheiden ja aus, wenn sie nicht via $PATH erreichbar sind,
> insofern kann man dem User die "Suchhilfe" wegnehmen.

Stimmt, hatte ich nicht bedacht.

> > Textmodus in Dialogshell, darf und soll aber X benutzen.
>
> Uh, da wirds schwierig, denn wer weiß schon, wer was in X
> alles aufruft...

Eben.

> > D.h. für sh würde ich also in /etc/profile einfach nur
> >
> > .if $USER=der_user ; then
> > chroot wohinerdarf
> > .fi
>
> Hat der Benutzer denn sh (oder wenigstens bash) als
> voreingestellte Shell? Sonst bleibt /etc/profile unbeachtet.

sh, klappt aber alles nicht. In /etc/profile nicht, weil da bereits mit
den Rechten des Benutzers ausgeführt wird.

> > Nur wie ich in passwd oder der Login-Klasse die Shell gegen ein Skript
> > oder die Verkettung von chroot "irgendwo" und der shell hinbekomme weiß
> > ich jetzt noch nicht. Skript könnte gehen, wenn keine Scherheitsbedenken
> > es verhindern.
>
> Also die Shell kannst Du in /etc/(master)passwd - idealerweise
> mit chsh - in Feld 10 setzen (siehe dazu "man 5 passwd"). Das
> Skript sollte sich im letzten Schritt durch die gewünschte
> Shell ersetzen ("exec /bin/csh" oder dergleichen).
>
> Die Login-Klasse wird über Feld 5 gesetzt, ihre Bedeutung wird
> in /etc/login.conf festgelegt. Da können Felder wie "path" oder
> "shell" gesetzt werden, was auch die Angabe in /etc/passwd
> übergeht. In "man login.conf" ist das sehr gut beschrieben.
>
> Allerdings sollte man dafür sorgen, das der User, in seinem
> Einfallsreichtum ungebremst, keine Chance hat, ~/.login.conf
> zu erstellen und gewünschte Barrieren damit eventuell zu
> durchbrechen! Eine Nulldatei, die ihm nicht gehört, stellt
> sicher, daß er da nicht rumfummeln kann.

Auch nicht wirklich, weil die shell ja wie oben als Benutzer x
ausgeführt wird und außerdem wird chroot dann jedesmal neu aufgerufen.
Gut, im Skript könnte man noch den ersten Lauf abfangen ...

> > Wie oben schon erwähnt, die Nummer mit den Links stelle ich mir eben
> > noch handhabbar vor, kompliziert wird es natürlich mit X.
>
> Richtig, da helfen dann Programme wie "htop" um nachzusehen,
> was da eigentlich läuft, und ob das auch so sein soll.

Schau ich mir mal an, nie gehört.

> > Aber man geht das Risiko ein, beim Skripten einen an der Marmel zu
> > kriegen ...
>
> Nur, wenn man es in Java skriptet. :-)

Hmm, naja. Die Sprache spielt da eigentlich keine Rolle mehr, irgendwas
fällt immer untendurch. Die mental verträglichste Lösung scheinen mir
grade jails zu sein, da haben wenigstens schon eine Menge Köpfe
vorgedacht.

> > Oder einen
> > isolierten Rechner aufstellen - nicht sehr reizvoll.
>
> Dann ist ein Jail doch das bessere - das ist ja fast wie ein
> isolierter Rechner. Bei einem realen isolierten Rechner besteht,
> je nach "krimineller" Energie des Users, auch die Gefahr, daß
> er in Sachen herumrührt, von denen er die Finger lassen sollte,
> und Du bist täglich damit beschäftigt, den Mist wegzuräumen,
> die der Bastelhuber Dir hinterlassen hat. :-)

Das wird mein nächstes Thema sein, die angedachte Lösung eskaliert
einfach in zuviele Unbekannte.

Vielen Dank für's mitdenken und anregen,

-- 
Marc Santhoff <M.Santhoff(at)web.de>
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 12 Feb 2010 - 12:30:29 CET

search this site