Wie kann die Socket-Erstellung für einen Linux-Prozess für Sandboxing deaktiviert werden?

Question

Ich erwäge mehrere Optionen für das Sandboxing eines Linux-Prozesses. Die Verwendung von clone() mit CLONE_NEWNET (usw.) ist eine der Optionen. CLONE_NEWNET stellt sicher, dass der Sandkastenprozess keine echten Netzwerkverbindungen herstellen oder akzeptieren kann. Aber ich möchte Sockets vollständig für diesen Prozess deaktivieren, sogar an einen beliebigen Port auf 0.0.0.0 und binden an einen Unix-Doman-Socket (auch anonym). Ich möchte dies tun, um zu verhindern, dass der Prozess zu viele Kernel-Ressourcen verwendet, indem er an Tausende von Ports bindet. Wie mache ich das?

Im Allgemeinen bin ich an vielen Sandboxing-Ansätzen interessiert (dh solche, die vom Linux-Kernel bereitgestellt werden und denen von ptrace() erzwungen), aber in dieser Frage interessiert mich nur der Socket-Erstellungsaspekt der Sandboxing-Ansätze (so Wenn Sie einen Sandbox-Ansatz vorschlagen, erklären Sie bitte auch, wie man die Socket-Erstellung verhindert. Ich bin nicht an Ansätzen interessiert, die ein Kernel-Patching benötigen oder ein Kernel-Modul laden, das nicht Teil des Standard-Binary-Kernel-Pakets von Ubuntu ist oder was jeden Prozess auf dem System beeinflussen würde.

Answer 1

ptrace scheint die naheliegendste Werkzeug zu sein, aber davon abgesehen, dass ...

util-linux [-ng] hat einen Befehl unshare, die die clone/unshare Schnittstellen des Kernels verwendet. Wenn Sie den neuen Prozess über (oder clone(CLONE_NEWNET)) ausführen, befinden sich alle Netzwerk-Sockets, die er erstellt, in einem anderen Namespace. Das Problem der Kernel-Ressource wird dadurch nicht gelöst, aber der Prozess wird in eine Sandbox umgewandelt.

Der Linux-Kernel unterstützt auch seccomp, ein Modus mit prctl(PR_SET_SECCOMP, 1) eingegeben, die den Prozess verhindert (gut, Faden, wirklich) vom Aufruf keine syscalls außer read, write, exit und sigreturn. Es ist eine ziemlich effektive Sandbox, aber schwierig mit unmodifiziertem Code zu verwenden.

Sie können eine SELinux-Domäne definieren, die socket/bind/etc nicht zulässt. ruft auf und führt einen dynamischen Übergang in diesen Typ aus. Dies erfordert (offensichtlich) ein System mit einer aktiv durchsetzenden SELinux-Richtlinie. (Möglicherweise ähnliche Dinge sind möglich mit AppArmor und Tomoyo, aber ich bin nicht sehr vertraut mit einem von ihnen.)

Answer 2

Werfen Sie einen Blick auf systrace - nicht auf Sockets beschränkt, aber eine generische Syscall Policy Generator/Enforcer. Quote:

GNU/Linux-Port ist fertig und Kernel-Patch wird aktiv von Marius Eriksen gepflegt. Kann ohne Kernel-Änderungen mit dem Ptrace-Backend ausgeführt werden.

Disclamer - Ich habe es nie unter Linux versucht.

Answer 3

Probieren Sie seccomp aus (siehe die prctl man-Seite), es kann Ihren Prozess darauf beschränken, nur auf die Sockets zuzugreifen, die zum Zeitpunkt des Aufrufs von prctl geöffnet waren.

Answer 4

Sie könnten mit „sydbox“ Sandbox oder „pinktrace“ Bibliothek interessieren:

Answer 5

Wenn Ihr Hauptziel darin besteht, die Anzahl der Sockets zu begrenzen, die von einem gutartigen Prozess P für gutartige Eingänge geöffnet werden, dann wird setrlimit(RLIMIT_NOFILE, ...) ungefähr das tun, was Sie wollen.Wenn P als bösartig und nicht als gutartig angesehen wird oder wenn Sie eine starke Gewissheit darüber suchen, wie P sich angesichts potentiell bösartiger Eingaben verhalten wird, dann haben Sie wahrscheinlich kein Glück: dh bei Am besten, mit den heute verfügbaren Tools können Sie einen Hindernislauf für Angreifer schaffen.

(aber sagte, dass, wenn ein Hindernis-Parcours für Sie arbeitet, dann könnten Sie ein paar mehr gute Ideen erhalten, indem um hier bei sandboxing.org Stossen oder indem Sie Ihre Fragen an den freundlich Leute auf sandboxing-talk@lists.sandboxing.org senden.)