Differences between sandboxing an AppImage vs using Flatpak version

[contrarybaton60]

I never really used the --sandbox flag since me and others came here to not have Flatpak's sandboxing (looking at you VSCodium) I just wanna know the differences, that's all.

[ivan-hc]

I don't use AppImage sandboxing either, to be honest:

• Both AM and Flatpak use Bubblewrap for sandboxes.
• Flatpak uses them by default, so to access (for example) a system theme, you have to install the Flatpak counterpart. AM uses Aisap as a frontend for Bubblewrap, so it can use system themes without problems.
• Furthermore, Flatpaks, precisely because they use sandboxing by default, are installed with preconfigured directory permissions that you have to change yourself, via Flatseal. On the contrary, in AM you have to decide which directories an application can see.

For everything else, I'll let @Samueru-sama and @mgord9518 speak

[mgord9518]

Hello, I'm the maintainer of aisap. Aisap permissions are somewhat "Flatpak inspired" but aren't the same. With aisap, you have a "base level" which essentially just allows read access to different system configurations.

Level 3 is the highest, only giving access to basic libraries, /bin, etc. It should primarily be used for CLI/TUI apps.

Level 2 is intended for most GUI apps, it also gives access to system themes, etc.

Level 1 is the least secure, it's intended for everything that for one reason or another, does not work properly with level 2. It gives full read access to /usr, /sys, /etc, all device files and a few others. It should only be used when nothing else can make the application function properly

No base level gives access to user files though (besides fonts and themes).

Then there are other permissions, such as sockets, devices, etc. Aisap stores all the app's files into a portable home folder which is compatible with AppImage (except for those explicitly requested by the permissions)

[Samueru-sama]

Worth mentioning that we use aisap a bit differently.

By default we deny access to all the xdg user directories (~/Downloads, ~/Documents, etc) and ask the user which directories they want to give access to.

We also give Level 2 to all the AppImages + read access to /usr/share, and give access to a directory in XDG_CONFIG_HOME and XDG_DATA_HOME that matches the name of the application, this is to avoid having to migrate the settings of the app when it is sandboxed. Our "~/.var" ends up being ~/.local/am-sandboxes but you can also move the location of the directory by setting the SANDBOXDIR env variable unlike flatpak in which ~/.var is hardcoded and cannot be moved.

[Samueru-sama]

looking at you VSCodium

Yeah I agree not everything can be sandboxed, even snap provides means to disable the sandbox, I think lite-xl has been stuck for 2 years trying to make a flatpak of the text editor as well due to having issues with the sandbox.

[contrarybaton60]

There is an official flatpak version of VSCodium (https://flathub.org/apps/com.vscodium.codium) but that's doesn't mean that you should use it. It's much more cumbersome to use due to Flatpak's sandboxing.

[ivan-hc]

in the AM database we manage the official AppImage of VScodium and the official bundle of VScode (code)

EDIT: however, only AppImages can be sanboxed through AM

[contrarybaton60]

yeah I know