Deeper integration with firejail for sandboxing

The appimaged daemon described here now uses an existing installation of firejail to run AppImages without the need of making them executable. firejail, in turn, uses in-kernel mounting, which should make the AppImages even a little faster to launch.

Right now this is experimental and the sandbox is very permissive (e.g., no restrictions are in place yet at all) but let’s think about how we can tighten up security (e.g., by letting unsigned AppImages run only in a fully sandboxed environment).

Firejail AppImage support and a few remaining issues with it are discussed at https://github.com/netblue30/firejail/issues/861.

1 Like

Any progress with that?
Is there an updated place to read about the current state of integration and policies?

No one has been working on this. Personally I am not very interested in the whole sandboxing thing (because my philosophy is that you should only run applications that you trust in the first place), but I will support anyone who is willing to work on it.

The problem is you can never trust the program even if it comes from the maintainer of the applications.

Take for instance the Transmission case.
Someone tampered with their files and anyone who downloaded their files got hurt (They even changed teh MD5 so even advanced user who verified the file was tricked).

It’s better have built in Sandboxing for regular downloaded AppImage (Assuming there is some kind of AppImage launcher).
Allow no Sandboxing only for applications user has specifically marked.

I’m not against using sandboxing, I’m just looking for someone who volunteers to work on it :wink: