Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
view the rest of the comments
AppImages have no sandboxing as you said. They also rely on the deprecated SUID-root binary FUSE2. AppImages are bad for security but they are convenient. A malicious AppImage could for example connect to org.freedesktop.secrets and access your keychain, or run a script that places a script called "sudo" in $HOME/.local/share/bin that is preferred over the real sudo and logs a password, or encrypt your files in a ransomware attack, or exfiltrate your session cookies from Firefox or Chromium browsers.
Flatpaks on the other hand are sandboxed. IIRC Flatpaks can't access other Flaptak's data folders in $HOME/.var/app (maybe even if home access is given?), 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. Modern apps that are designed to work as Flatpaks can use the xdg-desktop-portal to access only specific files/dirs upon user request, but it is only temporary access to a file. All the ways a Flatpak can access the system are defined by its permissions, so by giving more/dangerous permissions (such as devices or full filesystem access) a malicious app can possibly escape the sandbox and access arbitrary permissions. The worst permission an app can have is access to session bus for org.freedesktop.Flatpak, which allows it to arbitrary permissions, host command execution, and access to Flatpak configuration.
There is no such thing as a suid fuse2, you are talking about suid
fusermount, andlibfuse2which 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=1which makes them run without FUSE.The runtime still depends on a suid
fusermountinPATH(it checks all the way tofusermount99lol), 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.
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
I just realized your comment shows a Cromite AppImage? Where do you get that from?
https://github.com/pkgforge-dev/Cromite-AppImage