Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Zoom in firejail sandbox
Hallo allerseits,
nachdem ja an der FAU ja um Zoom nicht mehr herumkommt, habe ich mir eine Konfiguration Zoom auf Linux gebastelt:
- Zoom läuft in einer firejail sandbox
- Man muss kein Zoom-Paket installieren, es gibt kein Zoom-executable im $PATH.
- Es besteht also keine Gefahr, dass man es versehentlich außerhalb der sandbox ausführt
- In der Sandbox gibt es eine eigene Firefox-Konfig, sodass Login per SSO möglich ist.
Vielleicht ist es ja für euch nützlich.
Den code findet ihr hier: https://github.com/t-wissmann/zoom-firejail
2 „Gefällt mir“
Flatpak habe ich noch nie ausprobiert, deshalb kann ich es nicht sagen. Irgendwas hatte mich damals davon abgehalten flatpak zu nutzen…
Kleiner Hinweis: Sowohl flatpak als auch Firejail sind halt relativ dicke Setuidbinaries, und zumindest bei Firejail sind in den letzten Jahren auch immer wieder zuverlässig CVEs rausgefallen, teilweise auch etwas sehr offensichtliche, die man in einer Sandboxinglösung nicht erwarten würde wie “Ja wir konkatenieren uns mal einen String zusammen und werfen system drauf, ohne escaping und mit elevierten Privilegien, klar”. Flatpak hat den Sandboxingteil abgespalten in Bubblewrap und damit ein bisschen eine sauberere Trennung, dafür sonst nochmal viel mehr Überbau und Komplexität reingezogen mit Portalgestöpsel, etc.pp…
Insofern würde ich fast eher zu Einsatz von Zoom (wenn es denn der nativeclient sein MUSS) in einer VM raten. Da ist die Angriffsfläche zwar auch hoch, aber doch deutlich aktiver abgeklopft als bei Firejail/Flatpak. Zumindest USB-Webcams lassen sich auch problemlos durchreichen, Audio auch, sogar inklusive Pulseaudiointegration im Host bei Bedarf. Vor/Nachteil: die VM hat keinen Zugriff auf Fenster vom Host, insofern können dann nur Inhalte aus der VM geteilt werden so erforderlich. Alternativ kann man da (vermutlich, ungetestet) was mit virtuellen Kamerageräten via v4l2loopback frickeln, könnte aber widerlich werden.
Ansonsten kommt man aber vielfach auch mit dem Webclient in chromium aus; was mir als dysfunktional aufgefallen wäre: Umfragen funktionieren nicht, auch kann man nicht steuern welchen Videostream man erhält, sondern das scheint Zoom serverseitig anhand der letzten Sprecheraktivität auszuwählen. Selbst am Gespräch teilnehmen inklusive Screensharing funktionierte hingegen bei mir problemlos.
3 „Gefällt mir“
Kleiner nachklapp noch zu flatpack, weils mich dann grade doch kurz unter den Fingern gejuckt hat, da mal reinzuschauen, und man nicht sagen können soll, ich hätte das (verglichen mit firejail) irgendwem empfohlen :):
Aus der zoom-config unter https://github.com/flathub/us.zoom.Zoom/blob/25e14f8141cdc682b4f7d9ebe15608619f5a19f2/us.zoom.Zoom.json#L9
"--share=ipc",
"--socket=x11",
"--socket=pulseaudio",
"--share=network",
"--device=all",
"--filesystem=xdg-documents/Zoom:create",
"--env=QT_QPA_PLATFORM=",
"--own-name=org.kde.*",
"--talk-name=org.freedesktop.ScreenSaver",
"--persist=.zoom",
"--persist=.config"Pro: Dateisystem, vor allem das home wird gesandboxed
Contra: Ansonsten halt eher wenig; spätestens mit dem X11-Socket ist Sicherheit doch stark komprommitiert: das Programm kann ohne weitere Meldungen beliebige X11-Fenster außerhalb lesen (gut, das ist vielleicht sogar gewünscht(?)), aber eben auch in mein sudo-passwort abgreifen, ins root-terminal tippen…
Davon abgesehen bleibt halt auch sonst die Angriffsfläche, sowohl der Namespace-API im Kern als auch der flatpack-mechanismen wie Portale.
Was spricht eigentlich dagegen, einen extra Nutzer anzulegen, mit dessen Account einen zweiten X-Server zu starten (oder die Multisessionfähigkeit der gebräuchlichen DMs zu nutzen) und Zoom zu benutzen?
Das ist zwar nicht so bequem wie ein Fenster auf dem selben Desktop aber erscheint mir die Abkapselung deutlich einfacher zu realisieren als Flatpack, Firejail, VM mit RDP. Keep it simple, stupid.
Manchmal braucht man Screen-sharing schon. Zwischen zwei X-Sessions zu wechseln finde ich richtig unpraktisch, gerade wenn man z.B. an irgendwas arbeitet (unabhängig davon ob es in der Sitzung darum oder um etwas anderes geht). Evtl. reicht es ja zur abkapselung, die Zoom-Fenster in ein Xephyr zu verbannen.
Benutzt du Xephyr in deinem Firejail oder Xpra?
Sagen wir ein anderer Nutzer, Zoom in dessen Home installiert, was dann von dem Account aus im Xephyr läuft. Was sind hier die Nachteile ggü. Firejail? Fände ich interessant.
Bei einem anderen Nutzer müsste man erstmal die Verbindung zu Pulseaudio hinbekommen; da weiß ich nicht was man machen muss.
Bisher hab ich das mit Xephyr nicht probiert, aber wenn dann würde ich das versuchen mit firejail zu kombinieren.
Das Modulsystem von Pulseaudio erlaubt relativ einfach ueber einen Unix-Socket Zugriff zu ermoeglichen (mittels module-native-protocol-unix mit dem socket-Parameter). Auf der Gegenseite muss dann der PULSE_SERVER per Environment oder per X Property gesetzt werden.