Flatpak

[bertob]

In order to enable easy development/testing on GNU/Linux it would be cool to have a flatpak manifest. You could then also submit the app to Flathub.

[micahflee]

This might be a tricky project to package with flatpak because it runs containers itself, and flatpak sandboxes are run inside containers. And flatpak packages are supposed to be self-contained, but this relies on docker being installed -- I'm not sure it would be possible to package docker, and run docker containers, inside of a flatpak sandbox... but it's worth looking into.

[anarcat]

maybe the flatpak sandbox itself could be sufficient? just don't use docker in this case? this would then be similar to #95 (bubblewrap) because that's basically how flatpak does isolation anyways.

[rugk]

I agree it would be nice if you could publish this as a flatpak on flathub e.g.
Here is how to get started.

I guess the biggest advantage would be the secure and easy software distribution mechanism for most Linux distros (instead of exeuting random shell scripts downloaded via curl). can thus installed on any distro and are easy to update.

---

As for the technical part, first of all, AFAIK there are technologies to use Docker in Docker at least, so that may be possible. Generally, you could (and maybe should) use podman, which works rootless and may thus also be easier to integrate.

As for flatpak itself, I agree with what has been said, somehow I guess Chromium had the same issue but they are now on Flathub… 🤔

[rugk]

The project switches to podman, as it seems: #120

This is good, because I guess it also makes it easier to run in flatpak. The question would be: Can you actually run podman in flatpak? (It uses the same technology AFAIK.)

[micahflee]

It looks like it may be possible to create a Dangerzone flatpak package that works so long as podman is installed on the host. Then it can use flatpak-spawn to run podman from the host, e.g.:

flatpak-spawn --host /usr/bin/podman run docker.io/hello-world

The flatpak manifest will need a portal to allow this to work. I'll need to do more work to understand exactly how to get it up and running.

So, if we do make a flatpak package, you'll install it from flathub and then it might need to pop up a window saying something like: "To use dangerzone, install podman."

[rugk]

If you use flatpak-spawn you basically disable the sandbox (it needs DBUs access permission to Flatpak, no there is no portal for that). As such, this is no solution.

The question was rather whether installing and running podman inside of the flatpak could be made to work… 🤔

[pesader]

Flatpak has recently improved support for sub-sandboxes! Perhaps this will allow Dangerzone to be packaged as a Flatpak :)

https://github.com/flatpak/flatpak/releases/tag/1.12.0

[gasinvein]

You can run podman-remote (or podman -r) directly inside flatpak sandbox, without escaping to host (i.e. without flatpak-spawn --host), given that the app is permitted to communicate with Podman on host over its socket (--filesystem=xdg-run/podman). This is also a sandbox escape, though, but seems like a cleaner and safer approach.

[pesader]

@gasinvein Would that require Dangerzone to be forked just for the flatpak package? Or is there a way to do something like:

if flatpak then
    podman-remote --foo bar
else
    podman --foo bar

[gasinvein]

@pesader

Would that require Dangerzone to be forked just for the flatpak package?

No, unless the developer is unwilling to add flatpak-specific codepaths.

Or is there a way to do something like:

if flatpak then
    podman-remote --foo bar
else
    podman --foo bar

I think something like this should do.

[axtloss]

it would also be possible to solve it the way distrobox integrates with the flatpak vscode, the user would install dangerzone as a flatpak and then would have to put the podman-host script in the right location, which could also be done by dangerzone automatically

[sudwhiwdh]

Hello, thank you for the development of Dangerzone! Could you imagine adding this to your upcoming milestones?
And what would it take to make it happen from your point of view? Do you see a technically safe solution to implement this?

[deeplow]

We're not evaluating it at this time. We're moving our package deployment infrastructure from package cloud to the Freedom of the Press' infrastructure. This indicates ot me that that we'll keep supporting packages installation for linux as our primary method of distribution for the time to come.

We may re-evaluate in the future. Some of the challenges of Flatpak is that we use containers to make Dangerzone work, but the option to use VMs at some point in the future should not be excluded. Support for these are open questions that need to be answered before we can add flatpak (some of which have already been partly investigated by community members in the discussion above). These I would say are the main challenges with having this.

[axtloss]

The VM option would definitely be an option and work as I've flatpaked a similar application called entrusted using the VM image they provide.
you can view the manifest here although i can't guarantee that it works in it's current state

[orowith2os]

Coming back to this, you could download an OCI image and use flatpak-spawn to generate a container environment from that, like Podman.

Or use the flatpak-provided libraries (less work) and just sandbox the user files and everything. That would be preferable, as it's less download time and less ground to cover.

If necessary or desired, I may be able to assist.

[apyrgio]

Hey, thanks a lot for your interest on this issue! We'd definitely appreciate help from other folks, especially if they are familiar with Flatpak development. Unfortunately, due to other priorities, this issue has been lower in our list.

My understanding regarding the current solutions is that:

• flatpak-spawn can run an OCI image via podman run, but there are important limitations (Flatpak #45 (comment))
• A Flatpak application can contact a Podman daemon in the host, but this requires extra work from the user, and opens a huge gap for container escapes.
• Using Flatpack to run a VM is possible, but this would require providing a way to run Dangerzone within a VM, which we don't have yet.
• Dangerzone can use a Flatpak-native way to create sub-sandboxes (basically what you describe). In that case, we need to evaluate if Flatpak can achieve the following:
  • create an isolated, read-only filesystem,
  • enforce a limited seccomp policy,
  • create a separate user namespace,
  • drop all capabilities,
  • do not allow processes to gain root privileges

The last option is probably what has the most feature parity with Podman, but I'm not sure about:

• the maturity of bubblewrap (the container runtime that Flatpak uses), compared to runC (the container runtime that Podman users),
• the way we can harden containers (see above) using bubblewrap,
• any project that uses Flatpak libraries to enforce the same isolation Podman enforces.

An interesting PoC would be to clone the repo locally, run ./dev_scripts/dangerzone-cli within Flatpak, and then spawn ./dangerzone/conversion/doc_to_pixels.py in a sub-sandbox. This requires some hacks in the ./dev_scripts/isolation_provider/container.py, but it's the quickest way I can think of to showcase that we can use Flatpak native code for sub-sandboxes.

[axtloss]

Regarding the flatpak native way of doing it, most of the requirements are already met.
The entire root inside every flatpak is read only by default, flatpak limits seccomp (though I don't know if that's configurable), every flatpak-spawn creates a seperate namespace using bwrap and suid is not possible at all inside flatpaks.

Though I'm not entire sure about dropping all capabilities, that may be something flatpak already does by default.

Also an important thing to note, due to the way namespaces work it's not really a sub-sandbox, but more of a sandbox that runs next to the main one.

[gasinvein]

@apyrgio

• A Flatpak application can contact a Podman daemon in the host, but this requires extra work from the user

I'm not sure what kind of work on the users side is required, other than having the podman.socket user unit enabled.

and opens a huge gap for container escapes.

Again, not sure what exactly you mean here. If the app running inside the flatpak sandbox is allowed to communicate with the podman daemon, the app itself essentially can escape the flatpak sandbox, yes. But it doesn't affect what the processes inside podman containers the app creates can do, anyhow.

[axtloss]

I'm not sure what kind of work on the users side is required, other than having the podman.socket user unit enabled.

Having podman installed in the first place.
The user would have to install and set up podman to be able to even use this application, which not everyone knows or wants to do.

[apyrgio]

@axtloss:

Regarding the flatpak native way of doing it, most of the requirements are already met.

That's very interesting. Do you perhaps have any input on these questions as well?

• the maturity of bubblewrap (the container runtime that Flatpak uses), compared to runC (the container runtime that Podman users),
• any project that uses Flatpak libraries to enforce the same isolation Podman enforces.

If not, that's cool, and bubblewrap will still be (at least to me) the way forward.

Also an important thing to note, due to the way namespaces work it's not really a sub-sandbox, but more of a sandbox that runs next to the main one.

Does this hold for the user namespace as well? I think the translation of UIDs in the container to UIDs outside the container supports "nested" user namespaces, provided you have created the /etc/sub{u,g}id files correctly.

Having podman installed in the first place.

+1, that's what I had in mind. Also, the user must take care to not start a Podman service as root, which is reminiscent of Docker.

@gasinvein: I stand corrected! I erroneously had in mind that the Flatpak sandbox could be affected by malicious code, therefore the Podman socket would be under the attacker's control. This is wrong though, the Flatpak sandbox should be treated security-wise the same as the environment where Dangerzone runs, if installed via a .deb/.rpm.

The only security threat I can think of is the protection of the Podman Unix domain socket, so that other process in the system cannot write to it. This is a footgun, but inexperienced users may do it wrong.

[axtloss]

I can't really say anything about bubblewrap vs runC, as I don't have enough information about how runC works.

any project that uses Flatpak libraries to enforce the same isolation Podman enforces.

bottles and I believe steam do this, bottles has an option to sandbox applications that launches the process using flatpak-spawn, and steam runs the pressure-vessel runtime with flatpak-spawn too from what I heard.

Does this hold for the user namespace as well? I think the translation of UIDs in the container to UIDs outside the container supports "nested" user namespaces, provided you have created the /etc/sub{u,g}id files correctly.

I'm not sure how exactly this is handled with /etc/sub{u,g}id, but most of my attempts to run namespaces nested have resulted in them running side by side.

[gasinvein]

I'm not sure what kind of work on the users side is required, other than having the podman.socket user unit enabled.

Having podman installed in the first place. The user would have to install and set up podman to be able to even use this application, which not everyone knows or wants to do.

Well, indeed Podman needs to be installed in the first place, but it's also true for deb/rpm version, isn't it? Or it has podman package as a dependency?

set up podman

Set up how, exactly? AFAIK Podman autogenerates appropriate configuration on the first run and is should be usable OOTB. If it isn't, I'd agrgue it's a distro issue.

I think the ideal solution for the app would be checking if Podman is installed and, if not, using PackageKit to request its installation. This would require some work for sure, but still much less work than implementing whole new isolation mechanism atop Flatpak sub-sundboxes.

[rugk]

any project that uses Flatpak libraries to enforce the same isolation Podman enforces.

Many Electron apps (based on the Chromium engine) use Zypak for sub-sandboxing. I did not yet fully understand how it works, but maybe linking flathub/com.vscodium.codium#55 may help and you can see the links/linked implementation there.

[orowith2os]

Zypak replaces the Chromium sandbox with flatpak-spawn. You could achieve a very similar solution here, just replace Podman with flatpak-spawn.

I feel like there's some confusion on how this all works, and it's unnecessarily complicating it. Flatpak-spawn just spawns a Flatpak sandbox from the current environment, with additional limits or (within the limits of the inherited permissions) permissions.

It should be fairly easy to get going, but I'd like it if someone that works on dangerzone would be able to work with me on it.

[apyrgio]

@gasinvein:

Well, indeed Podman needs to be installed in the first place, but it's also true for deb/rpm version, isn't it? Or it has podman package as a dependency?

Yeap, Podman is a package requirement.

AFAIK Podman autogenerates appropriate configuration on the first run and is should be usable OOTB.

What does out of the box mean here though? My understanding is that to achieve zero user configuration, Podman would need to start a daemon with user privileges on startup, that will create a Unix Domain socket to a place where Flatpak can mount it. This is not something that Podman does automatically when you install it though.

This would require some work for sure, but still much less work than implementing whole new isolation mechanism atop Flatpak sub-sundboxes.

I agree, I'm hesitant as well. But if it's work that us devs can do and leave as less room to the end user for errors, I'd be willing to do it, provided that it is inline with our security requirements. And if it caters to people that are not power users, that's even better. Does this rationale make sense?

@orowith2os:

It should be fairly easy to get going, but I'd like it if someone that works on dangerzone would be able to work with me on it.

We're currently in feature-freeze mode, as we're about to release Dangerzone 0.4.2. After 0.4.2, we want to make Qubes support generally available, so that Dangerzone can be used in conjuction with SecureDrop. However, I'll try to allocate time for this task. Feel free to create a separate issue for this, where you can ask questions, or open a GitHub discussion, or even send me an email directly :-).