flatpak / xdg-desktop-portal

Desktop integration portal
https://flatpak.github.io/xdg-desktop-portal/
GNU Lesser General Public License v2.1
603 stars 194 forks source link

LXC portal #637

Open vchernin opened 3 years ago

vchernin commented 3 years ago

This might be necessary to run Waydroid (Wayland-only container based Android system) in Flatpak. An LXC portal would allow running Waydroid's LXC container within Flatpak's. It is probably a lot of work though, so I'm not sure how worthwhile it is.

See https://github.com/waydroid/waydroid/issues/64

smcv commented 3 years ago

Ability to run LXC containers is a very "powerful" permission, so it seems fairly likely that this would either be so "powerful" that it's effectively the same as arbitrary code execution on the host, or so limited that it's useless.

The reason that Flatpak generally forbids creation of new filesystem namespaces is that Flatpak and portals rely on all Flatpak apps' filesystem namespaces having /.flatpak-info, to identify them as a sandboxed app. If an app was able to run arbitrary code in a container whose root filesystem it controls, it would be able to hide or remove /.flatpak-info, which would make portals think that the processes in that container are non-sandboxed (part of the trusted computing base), similar to CVE-2021-41133.

Is use of LXC crucial to Waydroid, or does Waydroid merely want some sort of container with properties that it controls? Perhaps launching a Flatpak sub-sandbox for each Android app, and enhancing flatpak-portal to be able to set up those sub-sandboxes the way Waydroid wants them to look, would be more achievable?

The way Steam's container runtime interoperates with Flatpak might be a useful parallel here. When running without Flatpak, Steam's pressure-vessel tool creates a container to run the game in - it's not actually a security boundary, because it's only there to get a different filesystem namespace, but the idea is similar to Flatpak. When running with Flatpak, creating the new container would be disallowed by Flatpak, so instead pressure-vessel asks Flatpak to run a new "sub-sandbox", and I enhanced Flatpak to be able to give pressure-vessel enough control over what is in the new sub-sandbox (which was not previously possible). The security properties of the new sub-sandbox are still under Flatpak's control, and in particular the sub-sandbox still has /.flatpak-info.

hadess commented 3 years ago

If what's wanted is running Android applications, something like AnBox might be easier to adapt to running piecemeal inside a Flatpak container, rather than expecting a container that offers access to pretty much all of the native interfaces like Waydroid. Code is here: https://github.com/anbox/anbox/

orowith2os commented 2 years ago

Is this going to be possible anytime soon? I assume a portal like this would be VERY closely watched on who and what uses it, but it would still be a nice portal to have - especially since Waydroid would probably benefit from being used inside of a container.

Beryesa commented 10 months ago

https://github.com/containers/bubblewrap/issues/362 Found this but it seems to be in reverse

Beryesa commented 10 months ago

At least for waydroid, I guess figuring out a new project with more hardware portals on enhanced sub-sandbox (instead of privileged lxc) looks easier than porting waydroid for convenience.