https://github.com/pkgforge-dev/Cromite-AppImage

i was talking about the risk of a Flatpak which has access to user home and therefore could for example access $HOME/.firefox and steal session cookies.

Okay that makes sense.

Also I based my assessment of use FUSE2 for normal AppImages on the security hardening used by Secureblue, mentioned here under the section “Filling known security holes”

Remove the unmaintained and suid-root fuse2 by default.

kek they got it wrong. Also:

Mitigate LD_PRELOAD attacks via ujust toggle-bash-environment-lockdown.

Interesting, I wonder if they prevent executing the ld-linux.so as well.

There is two ways to preload libraries without having to modify the binary, the first is using LD_PRELOAD, the second is less well known but you can run binaries by calling the dynamic linker first (internally this is actually how all dynamic binaries you execute work btw) and then use the --preload flag to load a library.

That is instead of:

LD_PRELOAD=./kek.so /path/to/bin

you do:

/lib64/ld-linux-x86-64.so.2 --preload ./kek.so /path/to/bin

I’m going to take a wild guess and assume the second is still possible in secureblue 👀

AppImage is just a format, nothing is stopping distros from adding a binfmt_misc rule that makes all appimages be sandboxed with any tool. (this also means you can set this up so that they get executed inside a flatpak env btw)

They also rely on the deprecated SUID-root binary FUSE2.

There is no such thing as a suid fuse2, you are talking about suid fusermount, and libfuse2 which hasn’t been true for 3 years the runtime is now static and doesn’t depend on any libfuse (or any library) to work.

And even back then it wasn’t a hard dependency either, you could still run appimages by setting APPIMAGE_EXTRACT_AND_RUN=1 which makes them run without FUSE.

The runtime still depends on a suid fusermount in PATH (it checks all the way to fusermount99 lol), however there is a much better runtime that does not FUSE to work at all since it can use mount namespaces instead.

Meanwhile flatpak has a hard dependency on fusermount, it actually broke recently on ubuntu because they wanted to restrict access to fusermount.

but if given access to the “home” permission they can read and write to anywhere else in the user home, so stealing session cookies from a browser or ransomware could still be possible given the right permission.

web browsers (and electron apps) already have their own internal sandbox, which actually gets weakened by flatpak so it is actually not a good idea to be running those things with flatpak 1 2 3

firefox recently finally got a fork server in linux, which means it is possible to at least get the zypack hack working with it, no idea if it has been implemented yet though.

You also can sandbox appimages with bubblewrap, which is the very same sandbox flatpak uses, I wrote this tool used by AM for that.

Apps will also have access to the portals, although I don’t like this and looks like there is no easy way to disable access to portals other than disable all access to dbus which is bad.

We already had an incident where someone thought there was a sandbox escape when it was just the app opening the portal xd

https://github.com/ivan-hc/AM

Wouldn’t mind basically adding to a command or cron for something like apt-get get upgrade && flatpak update && something

iirc topgrade has support for AM, so you can do all at once with AM included.

In this case the issue is with 100% on flatpaks side that they decide to ship and download the entire nvidia driver again instead of using the one of the host. Note both snap and appimage do not do this, they use the nvidia driver of the host.

There is no reason to have to download the entire nvidia driver again, distros cannot modify it as it is against its license.

Also even outside of nvidia you are still going to have troubles in games with flatpak if what you are using requires a recent version of mesa

Be aware librewolf and all firefox based browser have security issues with flatpak because flatpak by forcing seccomp filtering breaks the internal sandbox of the browser:

https://librewolf.net/installation/linux/#security

Not to mention the librewolf flatpak is literary the portable tarball they release that works on your distro already, in other words it is the worst way possible to use librewolf.

And you only get that “ease of use” of being able to install it in the software store with one click because your distro did the pain of installing and configuring flatpak for you, otherwise it would have been much worse than what you posted.

Anyways, try using appman instead:

wget -q https://raw.githubusercontent.com/ivan-hc/AM/main/AM-INSTALLER && chmod a+x ./AM-INSTALLER && ./AM-INSTALLER

And then: appman -i librewolf which will “install” the AppImage and you can also sandbox it with am --sandbox librewolf and this sandbox does not break the internal sandbox of the browser unlike flatpak.