IMHO, Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources.
If you want to give that application access to everything your user has access to, that’s fine, but it shouldn’t be the default.
Yeah, I am obviously biased because I am a Red Hat employee but the truth is the Flatpak model makes a lot of sense for large desktop applications (LibreOffice, OBS, etc.) that anyway do Windows releases and therefore have to track vulnerabilities in their dependencies and release updates.
It may take a while to get used to it, but Red Hat has done a lot of infrastructure work to make this sandboxing possible (in RPM ostree, Flatpak, GTK+/GLib, PipeWire and many more places) and it's not a bad thing if they decide that the work is mature enough for them to reap the benefits.
This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged.
Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.
It is a program that reads unstrusted binary blobs (many document formats) using C++ deserialization code that has a history tracing back to the nineties and even eighties (through StarOffice). I sure as hell want such an application to be sandboxed and ask for elevated permissions. This is pretty normal on other platforms like macOS (Office and iWork from the Mac App Store run sandboxed), iOS, and Android.
Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.
You need more than policies. E.g. if a program cannot read outside its sandbox, you need some way to mediate access to files/directories on the user's request, which are provided by e.g. Flatpak/XDG desktop portals.
When opening any office files from unknown or untrusted sources is something you feel you have to do, you're probably well off isolating that operation and thus limit the blast area.
For people working exclusively on their own files or with trusted colleagues, that is pretty much a non issue.
First you say that people should just audit the code if they don't trust it. Then you say if someone wants to read untrusted files they should just spin up a virtual machine?
So I need to spend thousand of hours reading libreoffice's and its dependencies' code, and then I still need to run it in a virtual machine when I read untrusted files (in case there are bugs that could be exploited)?
It makes zero sense to keep pushing that nonsense when the alternative is to sandbox apps to begin with. It makes EVERYBODY safe from backdoors and bugs, for FREE. Why do you fight it?
Because of an intended functionality of many of those file formats, which makes them quite dangerous when coming from untrusted sources: Macros.
Compressed source code archive is over 300Mb. That's not a manageable amount for one individual, so I wouldn't expect it to be systemetically reviewed.
Much of it not interesting security wise.
> That's not a manageable amount for one individual, so I wouldn't expect it to be systemetically reviewed.
I settle for people thinking like attackers and going for the attack surfaces.
Sandboxes should be the must in this century and mobile OSs are much more ahead here.
I also enjoy stracing random programs in order to figure out the exact set of system calls they're making, in which order and with which parameters.
This isn't a knock on the value of package managers or maintainers. It's just an obvious step in better security. It seems silly to argue that integrity among package maintainers is the only safeguard we need. I personally like the little piece of plastic that my laptop has that slides across the built-in camera. It's not a software solution, or even an electronic safeguard. It's even better than the little DIP switch on my phone. I say, why not?
I don't know about "deserve" but it's true that we have the knowledge necessary to understand what a script or program is doing.
> There should never be any other way to offer trustability?
Of course not. Someone else can audit it for you. If you trust that person, then you also trust the software that they audited.
Linux distribution packagers are the simplest example I can think of. If something makes it into a Linux distribution like Debian, it's pretty trustworthy. That's a big reason why we users like that model. It's also why developers hate it.
I audit some of it sometimes. I trust that other do the same. Many hands make light work.
The distributor's job is to package software. In effect, putting it in their repo is sort of vouching for it-- they know it's going to work properly with the rest of the repo, and be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.)
If you just hand everything off to external self-contained images, you lose a lot of that.
I suppose you could do 'captive' collections of Flatpaks, designed to meet the same optimization and compatibility promises, but at that point, you have RPMs with extra steps.
Taken to an extreme, a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you.
To an extent, I also just resent the entire "it works on your machine? We'll ship your machine" mentality-- Docker/Kubernetes and Flatpaks/Snaps are sort of variations on the same theme. They come from a mindset of infinite free resources-- the disc space for all those redundant dependencies is coming from somewhere-- and it would seem to make brittle, hacky code more viable because you don't have to FIX code that depends on unguaranteed aspects of an API contract.
No, it looks a lot like Android or iOS, where the OS vouches for what the app can and cannot do instead of the distributor and there are no privileged scripts running at installation time. You can try it already with Fedora Silverblue.
> be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.)
That's true, this is potentially something that is lost for interested people.
Why would LibreOffice need access to microfone or location ? Asking for a friend.
I think I understand this stance, but really, I would consider this to be a terrible outcome. If that's the direction things are going, I really need to stop procrastinating my move away from Linux entirely.
But Flatpak doesn't ask the user to confirm any permissions, it silently grants any permissions that the application manifest might specifies.
OTOH, you don't need to change the packaging system to add sandboxing. It's perfectly feasible to sandbox with firejail or even just plain bubblewrap.