Re: User einsperren ohne jail

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

Am Freitag, den 12.02.2010, 05:37 +0100 schrieb Polytropon:
> On Fri, 12 Feb 2010 04:30:39 +0100, Marc Santhoff <M.Santhoff(at)web.de> wrote:

> > - nur bestimmte Programme (jenseits der systemeigenen Programme, also
> > nur für Programme unterhalb /usr/local/) von ihm ausführbar sind.
>
> Der einfachste Weg ist, $PATH auf die Verzeichnisse zu
> beschränken, die Programme enthalten, deren Ausführung
> erlaubt sein soll.
>
> Natürlich hält das den jeweiligen Nutzer nicht davon ab,
> per absolutem Pfad Programme aufzurufen. Das kann man
> mit o-x verhindern, allerdings müssen dann alle anderen
> Benutzer, für die diese Restriktion nicht gelten soll,
> in einer Gruppe sein, für die g+x erlaubt ist.

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.

> > Mein Problem beginnt schon beim Login, kann man dort gleich mittels
> > chroot(1) für Isolation sorgen?
>
> Wie loggt sich der Benutzer ein, per X-Login (xdm) oder
> im Textmodus, in eine Dialogshell? Man kann entweder per
> /etc/csh.login oder per /usr/local/lib/X11/xdm/GiveConsole
> entsprechende Anweisungen einbauen.

Textmodus in Dialogshell, darf und soll aber X benutzen.

D.h. für sh würde ich also in /etc/profile einfach nur

.if $USER=der_user ; then
        chroot wohinerdarf
.fi

Muß ich mal testen, ob das so klappt. Genau der Punkt, wie ich login
erzähle es soll die Wurzel verschieben, war mir unklar.

Beim rumgucken sind mir allerdings noch Login-Klassen aufgefallen, wenn
damit zu erreichen ist, was ich will, ist das eine möglicherweise
sauberere Lösung.

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.

> > Die Steuerung der Programmausführung dürfte mit geeigneten Rechten auf
> > dem Binary hinzubekommen sein, ist aber sensibel zu verwalten. Jede
> > Aktualisierung von ports führt ja schon dazu, daß die Rechte eventuell
> > nicht mehr passen ...
>
> Genau.

Wie oben schon erwähnt, die Nummer mit den Links stelle ich mir eben
noch handhabbar vor, kompliziert wird es natürlich mit X.

> > Ist das möglich, bekommt man so eine Konfiguration hin, ohne dem Irrsinn
> > zu verfallen?
>
> Zweckmäßig wäre vielleicht ein Skript, das im Anschluß an ein
> Update aufgerufen wird und prüft, ob auch alle Rechte wie in
> der Vorgabe sind und, da sie es üblicherweise NICHT sind, diese
> entsprechend der Vorgabe wiederherstellt.
>
> Dem Irrsinn kann man durch geeignete Skripte also sinnvoll
> vorbeugen. :-)

Aber man geht das Risiko ein, beim Skripten einen an der Marmel zu
kriegen ...

> > Oder sollte ich besser ein Jail aufsetzen?
>
> Ich möchte fast sagen, daß ein Jail die einfachere Lösung ist.
> Da ich das selbst aber noch nicht probiert habe, kann ich keine
> fundierte Meinung dazu abgeben.

Ja, scheint mir beim derzeitigen Stand auch so zu sein. Oder einen
isolierten Rechner aufstellen - nicht sehr reizvoll.

> > Oder noch eine andere Lösung benutzen, die ich nicht kenne?
>
> Tja, fällt mir auf Anhieb nichts ein, aber die anderen Listen-
> teilnehmer können Dir da sicher noch einen eleganteren Weg
> aufzeigen, sobald sie wach und vor ihrem Rechner betriebsbereit
> sind. :-)

Danke, hat schon weitergeholfen. :)

-- 
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 - 08:48:07 CET

search this site