grsecurity: unlogisches Verhalten mit TCP-Diensten im chroot

[daemotron]

Hallo,

ich habe auf meinem Server zwei chroot-Umgebungen eingerichtet. In beiden soll ein lighttpd laufen. Lighty1 soll sich an eth0 binden, Lighty2 an eth0:1. Natürlich sollen beide, nachdem sie sich lauschenderweise an die Ethernet Interfaces gebunden haben, die root-Rechte abgeben und unter einem unprivilegierten User laufen.

Soweit so gut, das ganze war kein Problem in der Umsetzung. Aktiviere ich jedoch die diversen Schutzmechanismen von grsecurity per sysctl, startet der erste Lighty problemlos. Der zweite hingegen kommt nicht hoch. Ich hab mir jetzt folgendes zusammengereimt (alles auf Dienste innerhalb eines chroot bezogen):

• Dienste, die an 127.0.0.1 gebunden sind, funktionieren problemlos
• Dienste, die an eth0 gebunden sind, funktionieren ebenfalls problemlos
• Dienste, die an eth0:x gebunden sind, funktionieren nur, wenn sie mit root-Rechten laufen (ein sshd z. B. tut's).

Kennt jemand von Euch dieses Phänomen? Wieso funktioniert der Lighty an eth0, der an eth0:1 aber nicht?

Hier noch meine grsecurity-Konfiguration:

Code: Select all

kernel.grsecurity.audit_mount = 1
kernel.grsecurity.chroot_caps = 1
kernel.grsecurity.chroot_deny_chmod = 1
kernel.grsecurity.chroot_deny_chroot = 1
kernel.grsecurity.chroot_deny_fchdir = 1
kernel.grsecurity.chroot_deny_mknod = 1
kernel.grsecurity.chroot_deny_mount = 1
kernel.grsecurity.chroot_deny_pivot = 1
kernel.grsecurity.chroot_deny_shmat = 1
kernel.grsecurity.chroot_deny_sysctl = 1
kernel.grsecurity.chroot_deny_unix = 1
kernel.grsecurity.chroot_enforce_chdir = 1
kernel.grsecurity.chroot_execlog = 1
kernel.grsecurity.chroot_findtask = 1
kernel.grsecurity.chroot_restrict_nice = 1
kernel.grsecurity.destroy_unused_shm = 1
kernel.grsecurity.dmesg = 1
kernel.grsecurity.exec_logging = 1
kernel.grsecurity.execve_limiting = 1
kernel.grsecurity.fifo_restrictions = 1
kernel.grsecurity.forkfail_logging = 1
kernel.grsecurity.grsec_lock = 1
kernel.grsecurity.linking_restrictions = 1
kernel.grsecurity.resource_logging = 1
kernel.grsecurity.tpe = 1
kernel.grsecurity.tpe_gid = xxx
kernel.grsecurity.tpe_restrict_all = 1

//EDIT//
Ich habe jetzt den Übeltäter durch stumpfes probieren entlarvt. Es ist die Option

Code: Select all

kernel.grsecurity.chroot_deny_unix = 1

In den Kernel-Hilfetexten findet sich dazu folgendes:

Code: Select all

CONFIG_GRKERNSEC_CHROOT_UNIX:

If you say Y here, processes inside a chroot will not be able to
connect to abstract (meaning not belonging to a filesystem) Unix
domain sockets that were bound outside of a chroot.  It is recommended
that you say Y here.  If the sysctl option is enabled, a sysctl option
with name "chroot_deny_unix" is created.

OK, klingt logisch, erklärt aber immer noch nicht, warum sich ein Lighty an eth0 binden konnte, der zweite aber nicht an eth0:1 *kopfschüttel*

[Roger Wilco]

Schlägt das starten der zweiten lighttpd Instanz auch fehl, wenn du auf das Alias eth0:1 verzichtest und die IP stattdessen (z. B. mit iproute2, `ip addr add <IP> dev eth0`) direkt eth0 zuordnest?

[daemotron]

Hallo Roger,

vielen Dank. Habe jetzt die Ursache gefunden. Es lag nicht an virtuellen oder nicht virtuellen Interfaces - die Umstellung auf iproute2 hat nichts gebracht (dafür bin ich jetzt wieder ein bisschen "moderner" ).

Der Übeltäter ist gamin, den ich anstelle von famd einsetze. In der ersten Lighty-Instanz wird gamin noch toleriert, in der 2., 3. und 4. aber nicht mehr. Folgendes konnte ich jetzt rekonstruieren: Wenn Lighty beim starten eine bereits existierenden gamin-Prozess aufspürt, startet er gamin nicht noch einmal für sich selbst, sondern versucht, den vorhandenen gamin zu nutzen. Und der lässt sich leider auch aus einer chroot-Umgebung heraus aufspüren.
Außerhalb der chroot-Umgebung:

Code: Select all

netstat -xlpen | grep fam
unix  2      [ ACC ]     STREAM     LISTENING     13988  5195/gam_server     @/tmp/fam-lighttpd-

Innerhalb einer fremden chroot-Umgebung:

Code: Select all

netstat -xlpen | grep fam
unix  2      [ ACC ]     STREAM     LISTENING     13988  -                   @/tmp/fam-lighttpd-

Es werden also lediglich die Prozessinformationen verborgen. Der Socket liegt aber natürlich außerhalb der anderen chroots, so dass lighty eben etwas verbotenes tut, wenn er versucht, den laufenden gamin für sich einzuspannen. und grsecurity reagiert natürlich promt und killt den lighty-Prozess, bevor der auch nur papp sagen kann. Tja, wenn ich nicht einen Weg finde, fremde Sockets vollständig vor einem chrooted-en Prozess zu verbergen, muss ich wohl oder übel auf gamin/famd verzichten...