Ausführung eines möglicherweise schädlichen Programms unter Linux

Ich schreibe ein Programm, mit dem ich Programme testen kann, die von Schülern geschrieben wurden. Ich habe Angst, dass ich ihnen nicht vertrauen kann und ich muss sicherstellen, dass es für den Computer, auf dem es läuft, nicht schlecht wird.

Ich dachte darüber nach, einen Crashtest-Benutzer mit eingeschränktem Zugriff auf Systemressourcen zu erstellen und Programme als dieser Benutzer auszuführen, aber von dem, was ich bisher im Internet gefunden habe, wäre es die sicherste Option, ein virtuelles System zu erstellen ...

Kann mir jemand bei der Auswahl des richtigen Ansatzes helfen? Sicherheit ist mir ein großes Anliegen. Andererseits möchte ich keine Lösung, die übertrieben ist und viel Zeit verschwendet, um etwas zu lernen, das ich nicht wirklich brauche.

• Die virtuelle Maschine bietet Ihnen die höchste Sicherheit ohne Neustart, aber die geringste Leistung.

• Eine weitere Option für eine noch höhere Sicherheit als eine virtuelle Maschine: Starten Sie eine "Live" -CD / DVD / ein "Live" -Pendrive ohne Zugriff auf die Festplatte (deaktivieren Sie die Festplatte vorübergehend im BIOS; wenn dies nicht möglich ist, mounten Sie das Laufwerk zumindest nicht / Hängen Sie es aus, wenn es automatisch angehängt wird - dies ist jedoch viel weniger sicher.)

• Ein Docker- Container ist eine etwas weniger sichere Alternative zu einer vollständigen virtuellen Maschine. Wahrscheinlich ist der entscheidende Unterschied (in Bezug auf die Sicherheit) zwischen diesen beiden Systemen, dass Systeme, die in Docker ausgeführt werden, tatsächlich den Kernel Ihres Host-Systems verwenden.

• Es gibt Programme wie Isolate , die eine spezielle, gesicherte Umgebung erstellen. Dies wird im Allgemeinen als Sandbox bezeichnet. Diese basieren in der Regel auf Chroot und werden zusätzlich überwacht. Finden Sie eine Umgebung , die zu Ihnen passt.

• Eine einfache Chroot ist am wenigsten sicher (insbesondere im Hinblick auf die Ausführung von Programmen), wenn auch vielleicht etwas schneller, aber ... Sie müssen einen ganzen separaten Stammbaum erstellen / kopieren und Bind-Mounts für /devusw. verwenden (siehe Hinweis 1 unten!). Daher kann dieser Ansatz im Allgemeinen nicht empfohlen werden, insbesondere wenn Sie eine sicherere und häufig einfacher einzurichtende sandboxUmgebung verwenden können.

Anmerkung 0: Zum Aspekt eines "speziellen Benutzers" wie demnobodyKonto: Dies gibt kaum Sicherheit, viel weniger als selbst eine einfachechroot. EinnobodyBenutzer kann weiterhin auf Dateien und Programme zugreifen, für die Lese- und Ausführungsberechtigungen für andere festgelegt wurden . Sie können es mit testensu -s /bin/sh -c 'some command' nobody. Und wenn Sie eine Konfigurations- / Verlaufs- / Cache-Datei haben, auf die irgendjemandnobodyzugreifen kann(aus Versehen oder aufgrund einer geringfügigen Sicherheitslücke), kann ein Programm mitden Berechtigungen darauf zugreifen und nach vertraulichen Daten suchen (wie "pass =" usw.) und in Viele Arten senden es über das Netz oder was auch immer.

Anmerkung 1: Wie Gilles in einem der folgenden Kommentare ausführte, bietet eine einfache Chroot-Umgebung nur sehr wenig Sicherheit gegen Exploits, die auf die Eskalation von Berechtigungen abzielen. Eine einzige chroot macht Sinn Sicherheit-weise, nur dann , wenn die Umwelt minimal ist,aus sicherheits bestätigte Programme nur (aber es bleibt immer noch das Risiko möglicher Kernel-LevelSchwachstellen) und alle die nicht vertrauenswürdige Programme in der chroot laufen laufen als Benutzer, der keinen Prozess außerhalb der Chroot ausführt. Was chroot (mit den hier genannten Einschränkungen) vorbeugt, ist die direkte Systempenetration ohne Privilegieneskalation. Wie Gilles jedoch in einem anderen Kommentar bemerkteSelbst dieses Sicherheitsniveau könnte umgangen werden, sodass ein Programm aus der Chroot ausbrechen kann.

Verwenden Sie eine virtuelle Maschine. Alles andere bietet nicht viel Sicherheit.

Vor ein paar Jahren habe ich vielleicht einen chrooted Dedicated User oder einen solchen vorgeschlagen. Die Hardware ist jedoch leistungsfähiger geworden, und die Verwendung der Software für virtuelle Maschinen ist einfacher geworden. Darüber hinaus sind Standardangriffe ausgefeilter geworden. Es gibt keinen Grund mehr, hier nicht den ganzen Weg zu gehen.

Ich würde empfehlen, VirtualBox auszuführen. Sie können die virtuelle Maschine in wenigen Minuten einrichten und anschließend eine Linux-Distribution darin installieren. Die einzige nicht standardmäßige Einrichtung, die ich empfehle, ist die Netzwerkeinrichtung: Erstellen Sie sowohl eine „NAT“ -Schnittstelle (um mit der Welt zu kommunizieren) als auch eine „Host only“ -Schnittstelle (damit Sie problemlos Dateien auf den und vom Host kopieren und in den SSH-Server kopieren können) die VM). Deaktivieren Sie die NAT-Schnittstelle, während Sie die Programme Ihrer Schüler ausführen¹. Aktivieren Sie diese Option nur, wenn Sie Softwarepakete installieren oder aktualisieren.

Erstellen Sie in der virtuellen Maschine einen Benutzer pro Schüler.

¹ _{Sie können die NAT-Oberfläche auf eine Whitelist von Benutzern beschränken, diese ist jedoch für eine einfache, punktgenaue Einrichtung weiter fortgeschritten als erforderlich.}

Hier finden Sie eine sehr ausführliche Erklärung, warum die Verwendung von Chroot immer noch eine sehr praktikable Option ist und warum die vollständige Betriebssystem- oder Hardwarevirtualisierung in bestimmten Szenarien besonders übertrieben ist.

Es ist nichts weiter als ein Mythos, dass Chroot kein Sicherheitsmerkmal ist. Es gibt Tools, die das Chroot-Dateisystem automatisch für Sie erstellen, und Chroot ist als zweckmäßige Sicherheitsfunktion in viele Hauptanwendungen integriert.

Entgegen der weit verbreiteten Meinung erfordert nicht jede Situation eine vollständige Virtualisierung des Betriebssystems oder eine vollständige Simulation der Hardware. Dies kann tatsächlich bedeuten, dass mehr Angriffsfläche zum Ausprobieren und Abdecken zur Verfügung steht. Dies bedeutet wiederum ein weniger sicheres System . (Angeblich für weniger sachkundige Systemadministratoren)

Die Regeln sind ziemlich einfach: Legen Sie nichts in die Chroot, was nicht notwendig ist. Führen Sie keinen Daemon als root aus. Führen Sie keinen Daemon aus, da ein Benutzer einen Daemon außerhalb der Chroot ausführt.

Entfernen Sie alle unsicheren Anwendungen, Setuid-Binärdateien und alle herabhängenden Symlinks / Hardlinks. Hängen Sie nicht benötigte Ordner mit nosuid, noexec und nodev wieder ein. Erstellen Sie die neueste stabile Version des laufenden Daemons aus dem Quellcode. und vor allem sichern Sie das Basissystem!

Ich werde dies hinzufügen, nachdem die Frage offiziell beantwortet wurde: MAGIC: Bösartiges Altern in Schaltkreisen / Kernen , das leider hinter der ACM-Paywall eingesperrt ist. Das Fazit des Papiers ist, dass die Spuren mit sehr geringer Breite in den heute verwendeten Schaltkreisen während des Gebrauchs altern und schließlich zusammenbrechen. Ein Angreifer kann ICs schnell bis zum Ausfall altern, indem er die richtigen Anweisungen findet und wiederholt.

Keine VM oder Sandbox, kein Container oder Chroot-Gefängnis würde diese Art von böswilliger Zerstörung der Hardware verhindern. Die Autoren des Papiers stellten fest, dass solche Anweisungssequenzen und experimentell gealterte Hardware versagen, gaben die Anweisungen jedoch nicht weiter, sodass sie für eine Weile keine echte Bedrohung darstellen könnten.

Unter von BSD abgeleiteten Unixen (einschließlich Mac OS X) gibt es eine Funktion namens sandbox. Die Manpage sagt

BESCHREIBUNG
Mit der Sandbox-Funktion können Anwendungen den Zugriff auf Betriebssystemressourcen freiwillig einschränken. Dieser Sicherheitsmechanismus soll potenziellen Schaden im Falle der Ausnutzung einer Sicherheitsanfälligkeit begrenzen. Es ist kein Ersatz für andere Zugriffskontrollen des Betriebssystems.

Dies ist getrennt von der chrootEinrichtung, die auch verfügbar ist.