Wird erwartet, dass Firejail R / W außerhalb der Sandbox ohne "--overlay" -Flag erlaubt?

1392
Emanuele

Soeben wurde Firejail auf Ubuntu 16.04 (Version 0.9.38 ) installiert und laut diesem Artikel des Linux-Magazins sollte R / O standardmäßig das gesamte Dateisystem sein:

Die Programme in der Sandbox haben nur lesenden Zugriff auf alle Verzeichnisse und können somit keine wichtigen Dateien bearbeiten.

Nun habe ich auf meinem Computer folgendes versucht:

  1. touch /disk5/test.txt
  2. firejail gvim /disk5/test.txt
  3. Ändern Sie die Datei und speichern Sie sie ( wq!)
  4. cat /disk5/test.txt
  5. zeigt Änderungen an, die von gvim während der Firejail- Sitzung vorgenommen wurden!

Ist das erwartete Verhalten? War das nicht firejail soll mich davor schützen, die Originaldatei überschrieben wird ? Was habe ich falsch gemacht? Bitte beachten Sie, dass /disk5es im Root-Dateisystem außerhalb meines eingebunden ist /home.

Ein Fehler in Github wurde behoben

5
Sie haben vergessen, die "--private" -Flagge an Firejail anzuhängen. Die "Man" -Seite besagt, dass nur "/ home" und "/ tmp" beschreibbar sind. Sind Sie sicher, dass Sie dies nicht unter Ihrem Zuhause versuchen? Oder einen Ordner oder eine Diskette unter Ihrem Zuhause oder so ähnlich? Das Überprüfen der Manpage ist auch hilfreich, da es unzählige verschiedene Optionen für Firejail gibt. "Man firejail" und sehen, welche anderen Argumente Sie benötigen könnten. Shiki vor 7 Jahren 0
@Shiki `/ disk5 / ...` ist außerhalb meines Hauses montiert, deshalb bin ich sehr überrascht ... Emanuele vor 7 Jahren 0

2 Antworten auf die Frage

1
VasyaNovikov

firejailist kein magisches Werkzeug, das alles richtig macht. Mit diesem Sicherheitstool können Sie Ihre eigenen Regeln für den Umgang mit Dingen definieren. Zum Beispiel diese Argumente:

firejail --noprofile

Gibt überhaupt keinen Schutz. Da Sie keine Einschränkungen angegeben haben, ist Firejail standardmäßig zulässig. Um einige Verzeichnisse schreibgeschützt zu machen, sollten Sie sie explizit schreiben. So etwas wie:

firejail --noprofile --read-only=/ --read-only=~ --read-only=/tmp

(Ich habe geschrieben /, ~und /tmpgetrennt davon, weil Firejail ein etwas überraschendes Verhalten hat, Ihre Anweisungen nach nicht ganz so trivialen Regeln zu sortieren und ~in der Mitte eigene Reittiere zu machen.)

Auch ohne --caps.drop=allArgumente --seccompund solche Programme sind Ihre Programme sowieso nicht sicher. Weil der Prozess über Unix-Sockets, abstrakte Sockets usw. mit anderen Prozessen kommunizieren kann, um deren Fehler auszunutzen. Wenn Sie ein relativ "OK-Gefängnis" wünschen, fügen Sie mindestens die Anweisungen seccomp, caps.drop = all und nonewprivs hinzu.

EDIT: Das Zitat, das Sie erwähnt haben, ist wahrscheinlich nur falsch. (Ich denke zumindest.) Es ist komplexer als nur "alles ist schreibgeschützt".

-3
joegasca

Warum sollten Sie Ihre Programme in einem nicht standardmäßigen Unix-Verzeichnis wie / disk5 aufbewahren? Sie bitten definitiv um Ärger. Speichern Sie Ihre ausführbaren Dateien an den regulären Orten, z. B. / bin, / usr / bin. / usr / local / bin oder auch / opt. Stellen Sie sicher, dass alle ausführbaren Dateien im Besitz von root sind und normale Benutzer keinen Schreibzugriff darauf haben. Linux ist ein Unix-System. Befolgen Sie einfach die Unix-Regeln und Sie sind sicher.

Ich kann es nicht wirklich, besonders wenn es sich um Software von Drittanbietern handelt, wie etwa Spiele von _steam_, meine eigenen kompilierten ausführbaren Dateien, die ich entwickle / baue usw. usw. Ich würde und könnte diese definitiv nicht unter dem System installieren bin pfade ... Emanuele vor 7 Jahren 4

Verwandte Probleme