-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gnome apps escape the jail #65
Comments
Hey, In theory any child process should also spawn in the network namespace. It works for me using nftables, Wireguard and normal rules (killswitch enabled, UDP tunnels - the standard vopono sync arguments for Mullvad) I think maybe the namespace is dying when the process forks, and maybe with iptables the killswitch isn't applying correctly. Try running vopono with the This didn't happen to me because I was running Firefox in the same vopono namespace. |
The namespace definitely dies when the process forks - |
Okay apparently it's not just qBittorrent. The same thing happens with gnome-terminal, and even with -k, it escapes. I think it might have something to do with the process invoked by vopono not actually being the parent process of the UI that's eventually pulled up. It might be similar to what Firefox does when already running, and not started with a new profile. Specifying -k is in this case reducing security, as without, you can clearly tell something is wrong by vopono exiting. It doesn't seem like something that can be properly solved by vopono. If a piece of software does this sort of session management, with a system tray icon, watching if it's already running, and independently started processes talking to each other, then it's pretty much impossible to reliably sandbox it without namespacing most of Linux (ie. running it in a proper container). I think printing a big red warning on the namespace going down might be a good idea... Like "the namespace is down, any applications still running are no longer routed through the VPN connection" or something. |
Thanks, are you able to trace what the parent process is in that case? As it'd be useful to know what causes it exactly (i.e. if Gnome is handling all apps like this). It works for fine for me using only i3 even with GTK3 apps. I'll try testing gnome-terminal too, it's a pain if it's a DE-specific thing. |
Okay, so I don't see this issue at all with qbittorrent on Arch Linux (it runs fine as its own process as usual) but is a big problem with gnome-terminal ! I'll leave this issue open for now and see if I can get some time to check more details in Gnome. It looks like it might be due to its client-server model: https://unix.stackexchange.com/questions/201900/run-true-multiple-process-instances-of-gnome-terminal Hopefully there'll be some sort of environment variable or config option to force it to run as a stand-alone process. |
Gnome-terminal has a server process gnome-terminal-server... A lot of modern GUI applications behave in a similar way, in that they keep running in the background, maybe with a system tray icon only, and if you invoke them again, they just ping the running process to open a window, and exit. Telegram does this, too, if it's running in the background, it will leave the jail. |
Yeah, but the issue is Gnome running that on startup, outside of the jail. Telegram is comparable to the Firefox/Chrome situation. Nevertheless, it's probably worth trying to improve the detection of these cases to at least flag it. So if the PID we created is not running, but another PID has the same name or something like this (we can't use the parent PID unfortunately). |
The message "Shutting down vopono namespace - as there are no processes left running inside" seems to be appearing erroneously when the namespace is still up. You can reproduce this by:
Vopono will say that there are no processes running in the namespace. Thankfully nothing outrageous happens - the namespace is still up, Firefox is still routed through the VPN... But it's still VERY confusing. I recommend only displaying that message if the namespace is really being taken down. |
This is potentially a big issue. It seems to happen by "accident" pointing to the sandboxing provided by vopono being quite porose. Here's the terminal output:
As you see, the process exits. And after it's exited, the qBittorrent GUI comes online. And...
That PID is not 96151! Through some kind of trick, the sandboxed qBittorrent process fails, maybe due to the dbus refusal, and... a completely different, non-sandboxed process is pulled up.
The reason I know this to be true is that I tested it with the Mullvad ip leak tool, and it does not go through the vpn at all.
The text was updated successfully, but these errors were encountered: