I'm the Never Ending Pie Throwing Robot, aka NEPTR.
Linux enthusiast, programmer, and privacy advocate. I'm nearly done with an IT Security degree.
TL;DR I am a nerd.
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.
- JumpRemoved
How do you deal with LUKS?
Maybe a setup FIDO2 LUKS unlocking, but that requires a security key: https://www.privacyguides.org/en/security-keys/
While I do find GOS drama a bit annoying, they aren't wrong about the lacking security of many AOSP forks. iode and /e/OS have a history late patches for security vulnerabilities in both the OS (https://web.archive.org/web/20241231003546/https://divestos.org/pages/patch_history) and for the forked apps they bundle with it. Each Android monthly and Chromium patches usually contains dozens High Risk CVEs, so taking a month or 2 is unacceptable. Neither are good for privacy or security.
See a comparison between some Android ROMs here, especially noting the update speed section: https://eylenburg.github.io/android_comparison.htm
- JumpRemoved
How do you deal with LUKS?
You could setup LUKS TPM unlocking.
To be more clear, antivirus in general are mostly scams because they are advertised to do much more than they are actually capable (especially proprietary ones that act as spyware such as Norton or Avast, which have been caught selling user data). Hash based antivirus solutions (such as ClamAV) aren't effective either because they rely on "badness enumeration", in which you try to determine all the bad samples (through a sample list(s)) and alert or delete them when detected. This isn't a good solution because a threat actor only has to add for example a single whitespace character into the code and it will produce a wildly different hash (which has not been sampled before). Badness enumeration is shit way to deal with real problems, much better is an allowlist approach, such as a permission system where to minimize the access given and soften the security until the app runs.
TLDR: Antivirus bad at job of stopping malware, and sandboxed apps good for security of your device.
An antivirus is mostly unnecessary when care is taken to not install or use untrusted software. If you install everything as a Flatpak (and modify some of the default permissions), you can avoid allowing software to gain much access to her computer.
While I think people suggesting Linux is immune to malware is stupid, for reasons such as it is "too secure" or "too niche" to be effected by malware, anti malware is like a bandaid to a gaping wound. If you have malware, it is already too late and you should first unplug the device from the network and any connected devices, backup any important data, and fresh reinstall by overwriting the infected install.
If you still think you need some way to defend against malware, use the VirusTotal website, or a native Flatpak called Lenspect, to upload and scan files (such as an executable binary). Lenspect requires no permissions other than network access, so it is safe and the only risk is if you input a file containing personal data it will be uploaded to VirusTotal.
Though to stress again, antivirus is a bandaid! The real solution is to be smart about what you install and only take stuff from trusted sources. Try to make sure everything is a Flatpak and avoid apps with excessive permissions, which weaken the security of the sandbox.
I get what you're saying, but i want to remind people: AI doesnt learn! LLMs don't think nor remember, it is only a fancy prediction model. It is more analogous to phone texting word prediction. It cant do anything remotely human-like.
Yes, which is why i very much like what GrapheneOS does with Storage and Contacts Scopes.
One word: Kudzu
Understandable. Though the security difference between Flatpak and Xen VMs, or even between Flatpak and Snap, is pretty big. Flatpak is mostly sandboxed to provide a consistent run environment to apps across distros, and id say 50% or more of the Flathub apps seem to have weak default sandbox security settings. Snap does a better job security-wise of reducing sandbox escape potential, but is still a far cry away from the containerization of Qubes.
Android doesn't expose any app data and requires a permission for accessing storage (unlike Linux).
Freebsd is also on distrowatch. Qubes is not desktop Linux because it doesnt function like normal linux. It uses the Linux kernel, but in a similar way to how Android isn't Linux, neither is Qubes.
Your hardware is most likely not free and open source. If you use non-free hardware, it is better to have security fixes then leave it unpatched. If you are using non-free hardware it doesn't matter how free your distro is, you still must depend on hardware blackboxes. Your hardware can directly interact with your distro and do something malicious regardless of the presence of firmware blobs.
Those distros (Fefora & Debian) are fully free, but acknowledge that hardware isn't in most cases. And like responsible and reasonable developers they choose what is best for stability and security.
I agree with PrivacyGuides on why to avoid Libre Kernels
https://www.privacyguides.org/en/os/linux-overview/#choosing-your-distribution
Linux-libre kernel and “Libre” distributions
We recommend against using the Linux-libre kernel, since it removes security mitigations and suppresses kernel warnings about vulnerable microcode.
AND
Proprietary Firmware (Microcode Updates)
Some Linux distributions (such as Linux-libre-based or DIY distros) don’t come with the proprietary microcode updates which patch critical security vulnerabilities. Some notable examples of these vulnerabilities include Spectre, Meltdown, SSB, Foreshadow, MDS, SWAPGS, and other hardware vulnerabilities.
We highly recommend that you install microcode updates, as they contain important security patches for the CPU which can not be fully mitigated in software alone. Fedora and openSUSE both apply microcode updates by default.
Definitely agree. If they could somehow make it a Flatpak with minimal permissions I would def check it out. Otherwise, I don't use any unsandboxed software to avoid apps having arbitrary permissions.
Understandable.
What part dont you agree with? I guess it can be more difficult for some people and depending on the documentation provided by the part manufacturers, it can be longer. I generally think PC building is easy.
There is more to xdg-desktop-portal than I said, it is quite powerful.
https://wiki.archlinux.org/title/XDG_Desktop_Portal
https://flatpak.github.io/xdg-desktop-portal/docs/
This Flatpak shows the power of portals on your system, while also requiring no permissions at all: https://flathub.org/en/apps/com.belmoussaoui.ashpd.demo
Same with this one, but it requires arbitrary permissions: https://flathub.org/en/apps/xyz.tytanium.DoorKnocker