“[GNU/]Linux being secure is a common misconception in the security and privacy realm.”
https://madaidans-insecurities.github.io/linux.html
“[GNU/]Linux is thought to be secure primarily because of its source model, popular usage in servers, small userbase and confusion about its security features. This article is intended to debunk these misunderstandings”.
Based on this, one should try to do as much as possible on a GrapheneOS device
Based on this, one should try to do as much as possible on a GrapheneOS device
To be clear, that is OP’s opinion, not a recommendation in the article.
Personally, I would be more interested in GrapheneOS if using it didn’t require (directly or indirectly) giving money to Google.
The author in another article does recommend GrapheneOS.
https://madaidans-insecurities.github.io/android.html
“The best option for privacy and security on Android is to get a Pixel 4 or greater and flash GrapheneOS. GrapheneOS does not contain any tracking unlike the stock OS on most devices. Additionally, GrapheneOS retains the baseline security model whilst improving upon it with substantial hardening enhancements … includ[ing] a hardened memory allocator, hardened C library, [and] hardened kernel”
on Android
GrapheneOS is still not perfect. The general consensus among people is that running QubesOS with a Whonix/Kicksecure container is the best you can get atm but even that it is not perfect.
The point of the Linux insecurities article is to fight common misconception by the FOSS community that using a Linux distro is going to solve every single security concern you might have. It does not mean, however, that Linux is inherently insecure and shouldn’t be used.
The author himself had said he uses Linux and Firefox despite what he wrote in the posts.
The real point is not that Linux is less secure than often said but that “inherently secure” is not a thing, especially not when a network is involved. Your system can make it easier for you but you still have to look after your own safety.
That’s pretty much what I have said
Yes; I was summarizing, not offering a differing viewpoint.
I would say QubesOS is for sure the safest, but having normal sandboxes and permissions should be enough. QubesOS is like making an insecure OS secure, as there are no permissions or portals, so you need to go way beyond and run multiple VMs at a time. This is not suited for any daily use, my modern laptop really struggles to run 2 VMs at a time
That’s why I buy secondhand Pixels. You can normally get near-new quality if someone orders one as a gift and it’s the wrong colour, or they accidentally chose the wrong storage size, or something similar.
That way Google’s not getting my money.
They’re getting money from people willing to pay for new Pixels knowing they can recover some of the cost later by selling them to you. (The used market bolsters the new market.) That’s what I meant by indirectly.
Please stop sharing bullshit articles full of technically uninformed disinformation
deleted by creator
First thing I read and it’s not even true.
Flatpak’s permissions are also far too broad to be meaningful. For example, many applications come with the filesystem=home or filesystem=host permissions, which grant read-write access to the user’s home directory
You can absolutely have more narrow permissions
For example, by default, Firefox only has read/write access to xdg-download and mpv only has read access to host and write access to xdg-pictures (to save screenshots). Discord by default only has read access to xdg-videos and xdg-pictures and write access to xdg-download.
I’m not even going to waste time reading the rest…
deleted by creator
Even if a flatpak app has full access to host, they can’t read the private data of other flatpak apps (~/.var).
deleted by creator
As far as I know, the only possible way to escape the sandbox is to use
flatpak-spawn --hostand add--talk-name=org.freedesktop.Flatpakbut I only ever seen that on apps like vscode.Imo, the point of flatpak’s sandbox is to give an extra layer of protection in case of security vulnerabilities. Permissions exist so apps can still work as they’re supposed to. It’s not a virtual machine isolated from the rest of the system where you can or should install malware.
Besides, the manifest is public and needs to be approved to be on the default repository.
Many applications come with home and host permissions
This is a true statement? As long as they are not rewritten partly to use portals, many especially big applications need that.
You’re correct, but just like you said, many applications need that.
If I install LibreOffice on Windows or Android, it’ll also have access to all my files. I really don’t see how that makes Linux more insecure.
Sure, ideally it would use portals, I just don’t like the attitude of the blog post.
Addressing concerns or areas for improvement, and suggesting users solutions like installing Flatseal, would be far more constructive. Even better would be submitting pull requests to enhance security themselves, since they seem to know so much about it. Instead, they’re just spreading FUD and complaining about small problems or nonsensical arguments like Windows adopting rust. Since when Rust is more used on Windows than Linux?
For instance, the blog post mentions Xorg’s security concerns but overlooks mentioning Xorg’s alternative Wayland, the default in most distributions when using KDE Plasma or Gnome, which are also the most used.
If security is so important, there are distros like Qubes OS, but most users don’t need that level of paranoia, specially if it ruins workflow, performance and productivity
Yes agree on that. Linux needs more standardization.
It is big problem, because it lacks the structure somehow. If there is easy tooling for app development, as Flatpaks with all the modern security practices (safe language, portals, modern GUI, Wayland, Accessibility APIs) then developers could easily follow these rules and create good apps more easily.
Currently app development is not easy and thus also very random.
Yes, you can have more narrow permissions, and the examples you listed are all valid and examples of apps with sensible permissions.
But since app developers can choose their apps permissions on their own, many apps have broad permissions like the access to the entire filesystem.
Some examples listed in the post:
GIMP, Gedit, VLC, Libreoffice, Audacity, VSCode, Dropbox and Skype
All of these have either the
filesystem=homeorfilesystem=hostpermission, giving the app acess to basically everything and compromising security.Flatpaks can have more narrow permissions but aren’t required to have narrow permissions. The post’s statement that many applications have broad permissions remains true.
Oh the FUD-blog again.
Irrelevant. Some systems may be hard to compromise but most humans are not.
privacy != security.
Try doing any serious work on a toy OS like Android, good luck.
I agree there needs to be a
- hardened kernel
- hardened malloc
- hardened C library
- SELinux confined user
- verified boot
- easy 3rd factor audit
- flatpaks that actually use portals
So Linux Distros like Fedora Atomic could get close to that, by shipping the hardened components etc. But for now, this would simply break apps. And having fully verified boot requires a custom BIOS or something else, like a bootloader on your USB stick or whatever.
deleted by creator
