Skip to content
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

LXC portal #637

Open
vchernin opened this issue Sep 27, 2021 · 5 comments
Open

LXC portal #637

vchernin opened this issue Sep 27, 2021 · 5 comments
Labels
new portals This requires creating a new portal interface

Comments

@vchernin
Copy link

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 waydroid/waydroid#64

@TingPing TingPing added the new portals This requires creating a new portal interface label Oct 26, 2021
@smcv
Copy link
Collaborator

smcv commented Nov 1, 2021

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
Copy link
Contributor

hadess commented Nov 2, 2021

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
Copy link

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
Copy link
Contributor

Beryesa commented Dec 28, 2023

containers/bubblewrap#362
Found this but it seems to be in reverse

@Beryesa
Copy link
Contributor

Beryesa commented Dec 28, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new portals This requires creating a new portal interface
Projects
Status: Needs Triage
Development

No branches or pull requests

6 participants