Wie erstellt firejail seine Standard-Blacklist?

Wenn ich anfange firejail, sehe ich mein komplettes Home-Verzeichnis. Wenn ich anfange firejail --whitelist=~/something, sehe ich nur somethingin meinem Zuhause. Nun möchte ich mehr Zugriff auf das System einschränken. Ich kann zum Beispiel hinzufügen --blacklist=/mediaund es funktioniert wie erwartet.

Aber wie bestimmt das Standardverhalten, dass /home/OTHERUSERund mit /home/*Ausnahme der weißen Liste Dateien versteckt ist? Ich sehe keine übereinstimmende Regel in /etc/firejail/*.

Und sind Unterverzeichnisse möglich? Zum Beispiel --blacklist=/media --whitelist=/media/datafunktioniert es nicht wie erwartet, auch wenn die Manpage mitteilt, dass die Whitelist andere Optionen überschreibt --read-only.

Sind diese Regeln in der Binärdatei fest codiert? Wenn nein, welche Regel macht das?

Ein Beispiel was ich gerne hätte. Grundregeln:

1. Haus leer, mit Ausnahme der im Profil aufgeführten Dinge
2. Schwarze Liste /media/data
3. Erlaube Symlink ~/apps ->/media/data/appsschreibgeschützt.
4. Lassen Sie /media/data/apps(wenn neccesary) schreibgeschützt.

1, 2 funktionieren, 3 arbeitet nur mit 4 (wahrscheinlich in Ordnung), aber das Überschreiben des Lesezugriffs für ein Unterverzeichnis eines verbotenen Verzeichnisses funktioniert nicht.

Es scheint ein wenig intuitiv zu sein, dass es funktionieren sollte, aber auf der Dateisystemebene mkdir -p foo/bar;chmod 111 foo;ls foo/bar/(wo 111bedeutet, dass es keine Berechtigung zum Lesen (dir-Listing) für foo gibt, aber nur das ausführbare Bit (Eingabe von Unterverzeichnissen) funktioniert, selbst wenn ein ls foo/Fehler auftritt.

Das erweiterte Szenario würde alle außer einer Whitelist (Profil + / usr, / bin, / lib usw.) nicht zulassen. Eine andere Sache, die ohne root nicht möglich erscheint (und dann läuft die App selbst als root), ist das Ersetzen von / etc / passwd durch einen Benutzer ohne Benutzer, der im Gefängnis nicht bekannt sein sollte. /etcenthält ziemlich viele lesbare Daten, die vor nicht vertrauenswürdigen Anwendungen verborgen werden sollten.

Aber möglicherweise würde das erweiterte Szenario einen vollständigen chroot + userspace-lxc-Container rechtfertigen.