-> (APACHE) -> Script unter CHroot des Owners ausführen

[Aquariophile]

Hallo!

/home/hacker/ ist unter chroot drin
Wenn ich ein perl script in seiner Shell starte,
das / ausliesst, dann geht das nicht,
weil sein persoenliches / ja in seinem Homedirectory liegt.

Soweit gut.
Nun kommt aber Apache und ruft 'dir.pl' auf,
und mit Apache kann man dann / auslesen weil es ja nicht der
user 'hacker' ist der chrooted ist.

Das script soll aber unter dem chroot unter der UID von 'Hacker' laufen.

'SuExec' von Apache tut da nix zur Sache das versuch ich seit ner Weile,
und heute sagten mit die Apache developer auch dass das echt ned so geht.

Ein Ansatz waere,
dass man in der httpd.conf ein Script reinbringt,
welches jedes Mal wenn der Suffix *.pl und *.cgi kommt,
ein Script startet,
welches dann mit 'su' unter dem Owner des CGI einloggt,
dann ausfuehrt, und das im Apache ausgibt,
aber ich denke das ist viel zu Aufwendig und vor allem
zu Lastig für den Server.

Danke!
Aquariophile

[Christoph Schnauß]

rehallo,

/home/hacker/ ist unter chroot drin

das heißt, es gibt ein Verzeichnis /home/hacker", das root gehört und worauf auch nur root Zugriff hat?

Wenn ich ein perl script in seiner Shell starte, das / ausliesst, dann geht das nicht

sofern du dich als root anmeldest, muß das gehen, oder dir den entsprechenden Scriptfehler anzeigen.

weil sein persoenliches / ja in seinem Homedirectory liegt.

?
Ein "persönliches /" gibt es nicht. "/" ist das Wurzelverzeichnis des Rechners. Je nachdem, ob du als root oder als Benutzer unter wegs bist und wie die Gruppenzugehörigkeiten eingestellt wurden, hast du darauf Vollzugriff, Lesezugriff oder gar keinen Zugriff.

Nun kommt aber Apache und ruft 'dir.pl' auf

Apache ruft gar nix auf. Du sagst ihm möglicherweise, daß er das Script "dir.pl" an den Perl- Interpreter weiterreichen und dessen Ergebnisse dir präsentieren soll

und mit Apache kann man dann / auslesen weil es ja nicht der
user 'hacker' ist der chrooted ist.

dann müßtest du möglicherweise in der httpd.conf die Gruppe neu justieren oder deiner Benutzerverwaltung sagen, daß in der Gruppe, die den Apache aufrufen darf, kein Benutzer stehen soll, der weiterreichende Rechte hat

Das script soll aber unter dem chroot unter der UID von 'Hacker' laufen.

Dann ändere die Rechte entsprechend

Ein Ansatz waere, dass man in der httpd.conf ein Script reinbringt,
welches jedes Mal wenn der Suffix *.pl und *.cgi kommt,
ein Script startet

halte ich für zu kompliziert und irgendwie "um drei Ecken herum" gedacht.

Ausschlaggebend ist (wenn ich dich richtig verstanden habe), daß deine Benutzer- und Gruppenverwaltung die geforderten Rechte korrekt verteilt. Aber ich werde den Verdacht nicht los, daß du _eigentlich_ irgendwas andres gemeint hast. Kannst du versuchen, deine Frage präziser zu formulieren?

Ach, und nochwas: ein "Script", das dir.pl heißt, den Inhalt von "/" ausliest und das Ausleseergebnis an einen Apache-Benutzer zurückgibt, ist ebenso verdächtig wie eine Webseite, die über ein ActiveX-Control "format C:" realisieren möchte.

Grüße

Christoph S.

[Christian Kruse]

Hallo Christoph,

bitte erkundige dich doch etwas, bevor du schreibst. Nur,
weil du es nicht kennst, heisst das nicht, dass es das nicht
gibt.

/home/hacker/ ist unter chroot drin
das heißt, es gibt ein Verzeichnis /home/hacker", das root
gehört und worauf auch nur root Zugriff hat?

'chroot' heisst, dass der Benutzer in dem Verzeichnis
eingsperrt ist. Fuer ihn sieht '/home/hacker' wie '/' aus.
Hat den Vorteil, dass der User nix boeses machen kann, aber
den Nachteil, dass man fuer jeden angelegten User eine
komplette Umgebung braucht, inkl. /etc, /bin, /usr/bin, /lib,
/usr/lib, /usr/share. Braucht pro User so ca. 100MB.

Ein "persönliches /" gibt es nicht.

Nachlesen, bitte. 'man 8 chroot', 'man 2 chroot'.

[... Apache-Absicherung ueber chroot ...]

Das ist keine einfache Sache. Letztenendes laeuft es darauf
hinaus, dass man sich selber einen Wrapper schreiben muss,
der die chroot-Umgebung aufbaut -- so aehnlich, wie du es
schon beschrieben hattest. Nur, dass man sich nirgendwo
einloggen muss, sondern dass das Script einfach root-Rechte
benoetigt und dann mit seteuid(2) und chroot(2) die richtigen
Einstellungen machen muss. Mit popen(2) kann man dann weiter
arbeiten.

Ich persoenlich wuerde davon abraten und das Rechte-System ausfeilen und entweder Apache2 einsetzen oder SuExec benutzen.

Gruesse,
 CK

[Aquariophile]

Hallo CHristian

man ln

jeder user braucht keine 100 MB
weil Du einmal ins /home/   eine Directory reinmachst
z.B. 'chroot' und da kommtn einmal die files rein und bei den
usern die unter chroot laufen kommen zwar die von dir besagten Directories rein aber nur mehr als symlinks bzw. inodes die verlinkt werden.

LG
Aquariophile

Hallo Christoph,

bitte erkundige dich doch etwas, bevor du schreibst. Nur,
weil du es nicht kennst, heisst das nicht, dass es das nicht
gibt.

/home/hacker/ ist unter chroot drin
das heißt, es gibt ein Verzeichnis /home/hacker", das root
gehört und worauf auch nur root Zugriff hat?

'chroot' heisst, dass der Benutzer in dem Verzeichnis
eingsperrt ist. Fuer ihn sieht '/home/hacker' wie '/' aus.
Hat den Vorteil, dass der User nix boeses machen kann, aber

den Nachteil, dass man fuer jeden angelegten User eine
komplette Umgebung braucht, inkl. /etc, /bin, /usr/bin, /lib,
/usr/lib, /usr/share. Braucht pro User so ca. 100MB.

Ein "persönliches /" gibt es nicht.

Nachlesen, bitte. 'man 8 chroot', 'man 2 chroot'.

[... Apache-Absicherung ueber chroot ...]

Das ist keine einfache Sache. Letztenendes laeuft es darauf
hinaus, dass man sich selber einen Wrapper schreiben muss,
der die chroot-Umgebung aufbaut -- so aehnlich, wie du es
schon beschrieben hattest. Nur, dass man sich nirgendwo
einloggen muss, sondern dass das Script einfach root-Rechte
benoetigt und dann mit seteuid(2) und chroot(2) die richtigen
Einstellungen machen muss. Mit popen(2) kann man dann weiter
arbeiten.

Ich persoenlich wuerde davon abraten und das Rechte-System ausfeilen und entweder Apache2 einsetzen oder SuExec benutzen.

Gruesse,
CK

»»

[Christian Kruse]

Hallo Aquariophile,

man ln

Bitte lies die Anleitungen, bevor du postest. Softlinks
koennen in einer chroot-Umgebung nicht mehr aufgeloest werden
und Hardlinks koennen weder auf Verzeichnisse, noch ueber
mehrere Devices hinweg angelegt werden.

Gruesse,
 CK

[Aquariophile]

Hallo Christian

Das geht.... ich schreibe gerade ein HOWTO dafür...
Wenn es fertig ist wird es auf einem Debian Server sein
und den Link dazu paste ich dann hier

so far...
Aquariophile

[Christian Kruse]

Hallo Aquariophile,

Das geht.... ich schreibe gerade ein HOWTO dafür...

By default, ln makes hard links.  A hard link to a file is
     indistinguishable from the original directory entry; any
     changes to a file are effectively independent of the name
     used to reference the file.  Hard links may not normally
     refer to directories and may not span file systems.

Gruesse,
 CK

[Sven Rautenberg]

Moin!

Hallo Aquariophile,

Das geht.... ich schreibe gerade ein HOWTO dafür...

By default, ln makes hard links.  A hard link to a file is
     indistinguishable from the original directory entry; any
     changes to a file are effectively independent of the name
     used to reference the file.  Hard links may not normally
     refer to directories and may not span file systems.

Mit anderen Worten: /home und /usr etc. müssen auf der gleichen Partition liegen, damit es funktioniert. Das bedeutet weiter, dass es unmöglich ist, diese Partition flexibel durch weitere Partitionen zu erweitern, indem man in den /home-Baum einfach weitere Partitionen mountet (quota für Arme ;) ). Und "alles in einer Partition" dürfte bei üblichen Installationen auch Seltenheitswert haben.

Es funktioniert, aber nicht allgemeingültig - und damit ist solch eine Lösung schlecht.

- Sven Rautenberg

[Christoph Schnauß]

guten Abend CK,

bitte erkundige dich doch etwas, bevor du schreibst. Nur,
weil du es nicht kennst, heisst das nicht, dass es das nicht
gibt.

Ich dachte eigentlich, ich hätte mich "erkundigt" und genau die manpages aufgerufen, die du weiter unten nennst. Daher habe ich vorsichtshalber nachgefragt (weil ich nicht sicher war, ob Aquariophile dieselben manpages nachgelesen hat):

das heißt, es gibt ein Verzeichnis "/home/hacker", das root
gehört und worauf auch nur root Zugriff hat?

'chroot' heisst, dass der Benutzer in dem Verzeichnis
eingsperrt ist. Fuer ihn sieht '/home/hacker' wie '/' aus.

kein Widerspruch. Ich habe so eine Konstruktion hier schließlich auch. Nur "gehört" dieses Verzeichnis auf meinem Rechner trotzdem root, und als user hab ich lediglich lesenden Zugriff.

Ein "persönliches /" gibt es nicht.
Nachlesen, bitte. 'man 8 chroot', 'man 2 chroot'.

hm. Du denkst hier aus der Perspektive des "users", und da stimmts, was du sagst. Ich habe aus der Perspektive des "Rechners" gedacht, und da bleibts halt dabei, daß es nur _ein_ "echtes /" gibt. Was der user als "/" unter diesen Bedingungen sieht, ist halt nicht das, was der Rechner als sein "/" behandelt.

[... Apache-Absicherung ueber chroot ...]
Das ist keine einfache Sache.

hab ich auch nicht behauptet.

Letztenendes laeuft es darauf hinaus, dass man sich selber einen | | Wrapper schreiben muss, der die chroot-Umgebung aufbaut -- so
aehnlich, wie du es schon beschrieben hattest

dann sind wir doch gar nicht so weit auseinander ;-)

Ich persoenlich wuerde davon abraten und das Rechte-System
ausfeilen und entweder Apache2 einsetzen oder SuExec benutzen.

und auch das ist nur eine ausführlichere und etwas ausgefeiltere Aussage als meine. In der "Substanz" haben wir uns nicht widersprochen.

Grüße aus Berlin

Christoph S.