.png)
Dies ist eine typische schroot.conf
Konfiguration, die ich verwende:
[label]
description=whatever
type=directory
personality=linux
preserve-environment=true
directory=/wherever
users=UserForSchrootOnly
profile=desktop_no_tmp
Keine root-users
Anweisung.
Separate Home-Verzeichnisse für die Schroot-Umgebung, ohne Verwendung von /home des Hosts.
Ich melde mich mit UserForSchrootOnly
dem Benutzer des Host-Betriebssystems bei diesen Schroot-Umgebungen an. Normalerweise füge ich diesen Benutzer zur /etc/sudoers.d/someConf
Datei hinzuinnenschroot, mit einer Linie,
UserForSchrootOnly ALL=(ALL:ALL) ALL
Eines meiner Ziele mit diesem Setup ist es, eine ziemlich isolierte Umgebung zu haben (nicht für eine strenge Isolation im Sinne einer Prüfung, aber in der Praxis effizient), sowohl durch Schroot als auch durch die Verwendung eines Betriebssystembenutzers nur für diesen Zweck und nirgendwo sonst. Andererseits ist es aus praktischen Gründen viel einfacher, diesen dedizierten Benutzer auch als Sudoer zu haben, natürlich innerhalb der Schroot-Umgebung.
Ein Anwendungsfall ist das Ausführen einer nicht vertrauenswürdigen Closed-Source-App.
Meine Sorge ist:
Da UserForSchrootOnly
der Benutzer ein Sudoer innerhalb der Schroot-Umgebung ist, kann dadurch die Sicherheit des Hostsystems beeinträchtigt werden? Gibt es eine Möglichkeit, innerhalb der Schroot-Umgebung Sudo-Erhöhungen zu verwenden, um auf etwas außerhalb von Schroot oder außerhalb UserForSchrootOnly
des Home-Verzeichnisses auf dem Hostsystem zuzugreifen?
Auf der Manpage von schroot.conf wird erwähnt, dass der Root-Zugriff auf chroot ein ernstes Risiko darstellt. Ich mache mir keine Sorgen über das Fehlverhalten des Benutzers. Meine Sorge gilt der nicht vertrauenswürdigen Closed-Source-App, die den Sudoer-Benutzer ausnutzt, den sie ausführt.
Ich möchte darauf hinweisen, dass dies zwar wie ein ideales Szenario für eine Sandbox wie aussieht firejail
, ich jedoch einige Apps damit nicht ausführen konnte, obwohl ich den --no-profile
Parameter hinzugefügt habe. Andere Szenarien umfassen auch Apps, die neuere Bibliotheken benötigen, sodass ich eine Debian Testing- oder Ubuntu-Schroot-Umgebung einrichten muss, um die nicht vertrauenswürdige App darin auszuführen.