And this is why I use Qubes and not Snap, Flatpak, or any of these other cobbled-together emperors-new-clothes app package managers. I knew this would happen from the very beginning but as usual, most software developers just shrug it off.
Flatpak – a security nightmare – 2 years later (2020)
131–140 of 296 posts
Re: Flatpak – a security nightmare – 2 years later (2020)
#132Earlier quoted context omitted.
> But that would require modifying the application Technically it can be done using LD_PRELOAD on fopen() and such.
Can it? If my application invokes syscalls directly, that wouldn't hit anything interposed using LD_PRELOAD.
Firejail[1] is IMO a good alternative. It handles sandboxing using Linux namespaces and seccomp-bpf.
Re: Flatpak – a security nightmare – 2 years later (2020)
#133Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flat... I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.
Great article, thank you for sharing.
I use Flatpak extensively and I fully agree with you and the author of the response that there is a need to balance practicality vs. idealism when it comes to (fully auditable) FlatPak apps, as well as FlatHub's overall approach and continual work within the desktop Linux ecosystem.
What's more, the fact that an entire domain was devoted to what could have been a blog post gives credence to the responder's notion that this is FUD which, while valid for discussion, is most certainly not beneficial to the FOSS community writ large.
Either way, from the article you linked TIL about Flatseal[0] so I'll be taking that for a spin!
Re: Flatpak – a security nightmare – 2 years later (2020)
#134Earlier quoted context omitted.
If macOS, iOS and Android can get away with one-time permission pop-ups when access is first needed, I'm sure the same model can be applied to Linux. The annoyance doesn't come from the security, it's from un-refined UX.
Escaping from annoying micromanagement pop-ups is a big part of why I use Linux. If this changes and it becomes as naggy as Windows I might have to move to Openbsd :)
Flatpak != linux. Different conversation.
Re: Flatpak – a security nightmare – 2 years later (2020)
#135I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, a…
I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?
Re: Flatpak – a security nightmare – 2 years later (2020)
#136Earlier quoted context omitted.
From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying. I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to cop…
Took me a while to figure out that Signal can't save outside of Downloads as well, especially since its not the default dir it opens when trying to save an file. There's no feedback of any kind. I see flatpak more as a distro independent package format than a way to secure my system.
More confusing one is that flatpaks can't access mount points inside your home directory even with the correct flatpak permissions set.
Assume that you are running Steam as a flatpak and you want to add an extra drive to store your Steam library on and you have your extra drive already automounted inside your home directory and the correct flatpak permissions set, Steam will not find it anyway.
You have to use a mount point outside of your home directory to get that to work.
Re: Flatpak – a security nightmare – 2 years later (2020)
#137Snaps for services, debs for user apps
Snaps suck for services because they auto-update and either restart daemons without warning or leave the running process in an undefined state.
Re: Flatpak – a security nightmare – 2 years later (2020)
#138Earlier quoted context omitted.
It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.
The technological ludditism is exhausting. We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake. Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.
> The technological ludditism is exhausting.
That sounds funny given the facts about Flatpak.
Re: Flatpak – a security nightmare – 2 years later (2020)
#139Earlier quoted context omitted.
In my view these queries about permissions are a bit meaningless. If an app asks me if I want to give it access to my Photos I feel uneasy about that. Which photos? For what? What is it going to do with it? I think the filesystem should be sandboxed and if an app wants to read something I should be able to e.g. give it a directory where it can do anything or I should be able to select a file and the app will have a p…
This is where we need to require better programming languages. What we need to be able to prove from code is that when an application is asking for a particular permission, the code paths the data will be used for can be shown not to result in network transmission without going through a trusted transform (if we want to allow it) - i.e. that only SHA512 transforms of that data can end up on the network without gating…
Why do you want a new language for this?
Re: Flatpak – a security nightmare – 2 years later (2020)
#140Earlier quoted context omitted.
In my view these queries about permissions are a bit meaningless. If an app asks me if I want to give it access to my Photos I feel uneasy about that. Which photos? For what? What is it going to do with it? I think the filesystem should be sandboxed and if an app wants to read something I should be able to e.g. give it a directory where it can do anything or I should be able to select a file and the app will have a p…
This is where we need to require better programming languages. What we need to be able to prove from code is that when an application is asking for a particular permission, the code paths the data will be used for can be shown not to result in network transmission without going through a trusted transform (if we want to allow it) - i.e. that only SHA512 transforms of that data can end up on the network without gating…
Is this really a programming languages thing? Feels like more of a framework issue to me, that the OS should be set up to pass apps already opened file handles for a lot of use cases where apps currently browse the filesystem and just do whatever.
Thinking similar to how systemd works with sockets— specify it in the unit file rather than needing to be launched as root so you can create it yourself and pinky swear you'll downgrade yourself afterward.