Improved sandboxing method for AppImages with revamped option --sandbox, dropping Firejail support in favor of "Aisap"

[ivan-hc]

In this change we get rid of the obsolete "firejail" and related option "--firejail" to implement a modern and more flexible method using the following tools:

• https://github.com/Samueru-sama/aisap-am by @Samueru-sama
• https://github.com/mgord9518/aisap by @mgord9518

AM users will need sudo to correctly enable the "aisap" sandbox for AppImages, to replace the symlink in /usr/local/bin with a script like this:

#!/bin/sh

# aisap-am sandboxing script
# Run this script with --disable-sandbox to do what the flag name implies

# Dependency check
if ! command -v aisap 1>/dev/null; then
	echo "You need aisap for this to work"
	notify-send -u critical "Sandbox error; Missing aisap dependency!"
	exit 1
fi

# Set variables and create sandboxed dir.
APPEXEC=DUMMY
chmod a-x "$APPEXEC" # Prevents accidental launch of the app outside the sandbox
SANDBOXDIR="${SANDBOXDIR:-$HOME/.local/am-sandboxes}/$(echo "$APPEXEC" | awk -F "/" '{print $NF}')"
DATADIR="${XDG_DATA_HOME:-$HOME/.local/share}"
CONFIGDIR="${XDG_CONFIG_HOME:-$HOME/.config}"
CACHEDIR="${XDG_CACHE_HOME:-$HOME/.cache}"
mkdir -p "$SANDBOXDIR"
if [ "$1" = "--disable-sandbox" ]; then
	APPIMAGEPATH="$(echo ${APPEXEC%/*})"
	echo "\n Giving exec permissions back to $APPEXEC..."
	chmod a+x "$APPEXEC" || exit 1
	echo " Patching $APPIMAGEPATH/AM-updater to give permissions back..."
	sed -i 's|chmod a-x|chmod a+x|g' "$APPIMAGEPATH/AM-updater" || exit 1
	THISFILE="$(realpath "$0")"
	echo " Replacing $THISFILE with a link to the AppImage...\n"
	SUDO ln -sf "$APPEXEC" "$THISFILE" || exit 1
	echo " \033[32m$APPEXEC successfully unsandboxed!\n"
	exit 0
fi
# Start at sandboxed home
# Edit below this to add or remove access to parts of the system
exec aisap --trust-once \
--level 2 \
--data-dir "$SANDBOXDIR" \
--add-file "$DATADIR"/themes \
--add-file "$DATADIR"/icons \
--add-file "$CONFIGDIR"/gtk3.0 \
--add-file "$CONFIGDIR"/gtk4.0 \
--add-file "$CONFIGDIR"/kdeglobals \
--add-file "$CONFIGDIR"/qt5ct \
--add-file "$CONFIGDIR"/qt6ct \
--add-file "$CONFIGDIR"/Kvantum \
--add-file "$HOME"/.local/lib \
--add-socket x11 \
--add-socket wayland \
--add-socket pulseaudio \
--add-socket network \
--add-device dri \
"$APPEXEC" $@

for more details visit the repository https://github.com/Samueru-sama/aisap-am

This is how to enable and disable the "aisap" sandbox

am --sandbox $APP
$APP --disable-sandbox

a quick view of the CLI interface

[ivan-hc]

Fix https://github.com/ivan-hc/AM/issues/659

[Samueru-sama]

@ivan-hc I'm surprised you will remove firejail. I didn't think you would do it, thank you so much.

Yeah firejail has a bad reputation now, and advertising it in am isn't a good idea.

Btw this change is BIG, getting bubblewrap sandboxing is like when appimages started using fuse3 instead of fuse2.

[Samueru-sama]

I added this to make the script launch am and install aisap without having the need to type am -i aisap.

elif ! command -v aisap 1>/dev/null; then
	echo " Error: You need aisap for this script work\n"
	read -p " ◆ DO YOU WISH TO INSTALL AISAP (y,n)?: " yn
	if echo "$yn" | grep -i '^y' >/dev/null 2>&1; then
		am -i aisap 2>/dev/null || appman -i aisap 2>/dev/null
	else
		exit 1
	fi	
fi

However that results in a double error for some reason:

However it still installs aisap anyway. So I guess I will just silence am completly lol.

EDIT: FIxed it, it is a hack but works lol

The double error is because I had am -i aisap || appman -i aisap and even because am -i aisap fails (but still installs the application lol) it then tries to install it again with appman.

When what I intended with that was try to use am and then appman. I don't know if there is an env variable that I could use there instead.

Because now it looks like this:

elif ! command -v aisap 1>/dev/null; then
	echo " Error: You need aisap for this script work\n"
	read -p " ◆ DO YOU WISH TO INSTALL AISAP (y,n)?: " yn
	if echo "$yn" | grep -i '^y' >/dev/null 2>&1; then
		am -i aisap >/dev/null 2>&1
	fi
	command -v aisap 1>/dev/null || exit 1
fi

And I don't know if is possible for appman to be installed but not am.

This is a very minor issue anyway

I tried to use "$AMCLI" -i aisap >/dev/null 2>&1 and that doesn't work? weird. ($AMCLI is empty)

[ivan-hc]

After I added your new module, this is what happens:

ivan@debian:~$ am --sandbox anydesk 
/opt/am/modules/aisap-sandbox.am: riga 9: [: --sandbox: atteso operatore binario
/opt/am/modules/aisap-sandbox.am: riga 28: command: --: opzione non valida
command: uso: command [-pVv] comando [arg ...]
strings: "": questo file non esiste
  doesn't look like an AppImage, aborting

[Samueru-sama]

After I added your new module, this is what happens:

ivan@debian:~$ am --sandbox anydesk 
/opt/am/modules/aisap-sandbox.am: riga 9: [: --sandbox: atteso operatore binario
/opt/am/modules/aisap-sandbox.am: riga 28: command: --: opzione non valida
command: uso: command [-pVv] comando [arg ...]
strings: "": questo file non esiste
  doesn't look like an AppImage, aborting

Uh oh. but why? All that should have been done is replace the wget for the path to the module?

[ivan-hc]

Uh oh. but why? All that should have been done is replace the wget for the path to the module?

@Samueru-sama never mind. I've already fixed everything and tested everything with AM and AppMan, even removing "Aisap" for both, in the lates 2 hours.

[ivan-hc]

All changes I've made are around your module, that I've renamed "sandboxes.am" and then reimplemented/refactored also the -H option. So your module takes the place of the old sandboxes.am

[Samueru-sama]

Uh oh. but why? All that should have been done is replace the wget for the path to the module?

@Samueru-sama never mind. I've already fixed everything and tested everything with AM and AppMan, even removing "Aisap" for both, in the lates 2 hours.

Thanks but this looks like a bug nonetheless. I just tested trying what I originally had in mind with the module being a script basically:

chmod says that it is not a directory? It is not indeed but why does it say that. First time I see such error.

I don't want you to rollback the changes just in case, just that I find that error very weird.

[ivan-hc]

have you updated using --devmode-enable?

[Samueru-sama]

have you updated using --devmode-enable?

I didn't do on purpose, I still have the old script on $AMCACHEDIR that I moved to $AMCLIPATH/modules and renamed to sandboxes.am since this is all that needed to be done in theory.

When I do that it doesn't work for some reason. I know you fixed it in a different way, just that I found that issue weird.

[Samueru-sama]

Anyway I've tested the changes you did and it is all working.

[ivan-hc]

@Samueru-sama I think we are ready. Also the README has been updated. I'd like to add a brief video in the meantime.

[Samueru-sama]

@Samueru-sama I think we are ready. Also the README has been updated. I'd like to add a brief video in the meantime.

I suggest you use librewolf for the demo. As aisap also gives it access to ~/Downloads.

[ivan-hc]

I just showed how to run the command and reference links for further reading. On the other hand, in the example there are Anydesk and Lxtask, and the latter is the only one that works in sandbox.

[ivan-hc]

All the important links for documentation have been listed. Also the "Aisap" project will get more interest and support after this update. @mgord9518 will get much more attention and support from developers and users. Guaranteed.

[ivan-hc]

I forgot to add info about .am-sandboxes on the README, @Samueru-sama can you add these for me?

[Samueru-sama]

I forgot to add info about .am-sandboxes on the README, @Samueru-sama can you add these for me?

I'm sorry but I'm not very sure how the formatting should be there.

You can use the header of the original script as reference though:

	# This script makes it easy to sandbox AppImages installed with AppMan or AM
	# The default location for the sandboxed homes is at $HOME/.local/am-sandboxes
	# But that location can be changed by setting the $SANDBOXDIR env variable
	# aisap: https://github.com/mgord9518/aisap

And maybe highlight that this sandbox method uses bubblewrap.

[Samueru-sama]

Btw @ivan-hc I'm going to archive the original aisap-am script. so I don't know if it is a good idea to link to it.

[ivan-hc]

You're just archiving it, right? You're not deleting it, I hope.

Let's say someone in the future wants to create a sandboxing method for all locales, without "AM".

What better tool than your script?

[Samueru-sama]

You're just archiving it, right? You're not deleting it, I hope.

Let's say someone in the future wants to create a sandboxing method for all locales, without "AM".

What better tool than your script?

Yes just archiving it.

[ivan-hc]

Released https://github.com/ivan-hc/AM/releases/tag/6.12

[Samueru-sama]

Released https://github.com/ivan-hc/AM/releases/tag/6.12

What do you mean version 6.12 😭

This wasn't that small of a change, but anyway it is just number lol.

[ivan-hc]

This change is great, but its far from a version 7:

• Version N.N.N-N, minor bugfixes, it does not need to be announched;
• Version N.N.N, improved a single option;
• Version N.N, new option or there are so many improvements that they deserve to be very important;
• Version N, a structural change of the whole CLI.

That said here are the main versions:

1. Sep 6, 2021: when AM was not already created, this was the first draft of AppMan, before I abandoned it. This was a draft that creates a /opt/bin directory containing all the apps... so something against the Linux Standard Base. I was so inesperienced;
2. Dec 17, 2021: the first release of AM, because its born from the first failed attempt to create a package manager for AppImages, named AppMan (also, since the name was already used, I've named is AM, to made it quick and easy);
3. Mar 26, 2022: a lot of options with multiarguments support and a reimplementation of pkg2appimage to speedup building applications on-the-fly (because yes, AM can act as an AUR helper like this);
4. Oct 23, 2022: change in the Github APIs, so I had to update 800+ installation scripts, and also I started converting a lot of pkg2appimage-based scripts by starting creating AppImages by myself;
5. Dec 9, 2023: "AM" and AppMan merged together;
6. Feb 14, 2024: switch from a monolitic model to a modular one.

@Samueru-sama I don't know what will determine the release 7 in the future, nor I know if there will be one... but this is not the case.

Fun fact, since Jun 6, 2022 the issue number 8 of this repository is still opened. The one about the GUI. So we were between release 3 and 4. So it is opened from two years and 10 days.

[Samueru-sama]

I see, but remember that now the changes are being done little by little.

• Some modules were optimized

• There is an even appimage template now

• We have bubblewrap sandboxing

On their own they seem like small things, but together they are a bigger change. This is like the ship of theseus, at some point all these small changes accumulate AM will be vastly more different than the AM that was a few months ago.

But anyway, it is just a number. What matters is am itself.

The one about the GUI

Btw did you test the vappman GUI? I couldn't ge it to launch but that is me fighting with the python package manager lol.

[ivan-hc]

Btw did you test the vappman GUI? I couldn't ge it to launch but that is me fighting with the python package manager lol.

I'm not a Python fan, nor a PIP fan at all.