Distributors entering Flatpakland
Distributors entering Flatpakland
Posted Jul 9, 2022 13:19 UTC (Sat) by pabs (subscriber, #43278)In reply to: Distributors entering Flatpakland by alonz
Parent article: Distributors entering Flatpakland
Posted Jul 9, 2022 15:22 UTC (Sat)
by smcv (subscriber, #53363)
[Link] (11 responses)
For networking specifically, it's rather all-or-nothing: bubblewrap can either keep the app in the same network namespace as the real system (meaning it can do arbitrary TCP/UDP), or unshare the network namespace (meaning the app can only access its own private loopback interface). At the low level where bubblewrap operates, there's no middle ground available. If someone puts in the necessary work, it might be possible to unshare the network namespace and then put in a filtering proxy between the app's netns and the real system using something like slirp4netns, but that filtering proxy is going to have to make authorization decisions based on the minimal amount of information that it can screen-scrape from what it sees.
The UI for portals tends to work best in terms of being user-comprehensible when they're acting at as high a level as possible, because that gives them the information they need to do their jobs, rather than having to try to reverse-engineer what an app is trying to do from the low-level actions that it carries out.
One thing that can be particularly problematic is when an action has traditionally been quick and not involved any decisions or user interaction, so an application would traditionally have done it synchronously, but a portal needs to intercept it and get a decision. For instance, this is one of the reasons Flatpak has a static permissions mechanism to allow or deny access to the home directory, instead of making all file I/O interactive by putting a FUSE filesystem between the app and the real storage: if it did that, then many apps would end up frozen and unresponsive (not even able to respond to routine Wayland/X11 messages like copy/paste, window movement, or being closed) while blocking in an open() that had resulted in the user being prompted.
Posted Jul 9, 2022 15:42 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (10 responses)
Now, network. Since we’re using portals for many things and it’s ok, can we also use them for the network access? Since we can have per-program network namespace, every program can have a veth interface which can be firewalled as tight as we like it. Can we have and enforce the HTTP/HTTPS access via the portal only, which can grant it with the desired granularity (obviously, the portal needs to know the URLs to make decisions, thus a separate API for HTTP(S))? As the rest of the protocols goes, we could instead firewall it at the veth interface.
An added benefit could be that some apps which, say, spin an HTTP server internally for IPC or whatnot, could do so very privately. The protection could go both ways.
The latter is important because even at Apple they have realized that LAN access for any random app out there can be a vector attack, and LAN connection is a special kind of permissions now.
Posted Jul 9, 2022 17:48 UTC (Sat)
by atnot (subscriber, #124910)
[Link] (9 responses)
Much like on Android, files and directories should primarily be opened through the portal interface. This will open a native file chooser interface for the user and then only expose those files and directories to the app. If you are using Qt or GTK this will work automatically without any extra code. There are also more fine-grained filesystem permissions available[1], e.g. "xdg-config/appname:ro" would share the user's config for your app as read only. The mechanism is definitely there and many applications do use it.
However it is true that in practice there are a few policy caveats: For one, most applications were written without filesystem sandboxing in mind and few application developers are really willing to put in much effort to support them. Just blasting a big hole in the sandbox is an easy way to get the errors to disappear. Secondly, because these permissions are too cryptic for most people to understand, they are automatically granted at installation time. So unless you carefully audit every permission with a tool like flatseal, you are only as protected as the maintainer of the package wants you to be. However, these policy decisions are easy enough to adjust later, the important thing is that being opt-in, they can be changed now.
> If I have an app I trust, I don’t need flatpak, goes without saying.
With such a strictly binary model of trust, I presume might also be choosing to run all of your processes as root on a nommu kernel. In that case Flatpak will definitely not help much.
[1] https://docs.flatpak.org/en/latest/sandbox-permissions.html
Posted Jul 9, 2022 18:48 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (7 responses)
Why "all"? I meant that in my current workflow where I run programs as curated by, say, Fedora maintainers, I can have reasonable trust in those programs not accidentally stepping all over my files, and thus sandboxing offered by flatpak is not, strictly speaking, needed. They add nothing.
> Secondly, because these permissions are too cryptic for most people to understand, they are automatically granted at installation time. So unless you carefully audit every permission with a tool like flatseal, you are only as protected as the maintainer of the package wants you to be.
But wait, isn't flatpak there for my security? I thought it was being made specifically so we could run potentially untrusted code without it doing much harm? And now I learn that not only security is optional, but it's fully in the hands of this untrusted maintainer, and those permissions will just... be silently granted. What you said just effectively negated each and every privacy- and security-related benefit flatpak might have.
Posted Jul 9, 2022 19:40 UTC (Sat)
by atnot (subscriber, #124910)
[Link] (6 responses)
Chosing not to pester the user with permission prompts at installation time is just a pragmatic policy choice that accounts for the realistic user risks, the degree to which most applications can actually be sandboxed on linux in the first place (anything with access to X or pulseaudio is right out) as well as the risk of developers refusing to support flatpak or people deciding it's a bigger hassle than just downloading random binaries off of websites instead. If flatpak is succesful enough, it is easy to just enforce stricter policies during installation, the metadata is already there.
Posted Jul 9, 2022 19:51 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (5 responses)
For example, software business gets bought and sold. What if the alignment of the current owner is not the same as that of the previous one?
X.0 software is ok, X.1 carries adware in addition to its useful functionality.
A software which is demanded by an employer is, in addition to providing stated functionality, invades privacy in numerous ways. (Zoom is an example of software which is walking a very fine line between being useful and falling into total shoddiness, and is required by many.)
A program starts carrying, say, Facebook SDK.
In the world of mobile (and maybe Windows), where there is proliferation of apps, you hit these bad apples all the time. Flatpak is after the same kind of apps proliferation, so you can expect all antipatterns known in App Store/Play Store to also appear there once they succeed.
But I get it, learning from past mistakes and current mistakes of the competition is *hard*. Let’s grow, let’s hype what we don’t have, let’s fix it later or maybe never.
Posted Jul 9, 2022 20:39 UTC (Sat)
by atnot (subscriber, #124910)
[Link] (4 responses)
Please do tell me what your alternatives are. Offering a grand selection of five GNOME apps? Giving users alert fatigue by showing a big red banner for every large application? Hosting broken applications and ensuring the users' next course of action is purging Flatpak? (Snap has been very good at that.) The Flatpak developers coming in and personally porting every codebase to Wayland and Portals (including proprietary ones like Zoom)? I disagree, Flatpak definitely learned from competitors like UWP in what happens if you try to force people to do things your way overnight.
I get that you want Flatpak to be more than it is. I agree that what you're describing would be wonderful. But what I also see is that it is already a significant increase in security for the average user over what we have right now and lays the technological foundations for it being even more secure in the future. I'm willing to cut it some slack on the things it needs to compromise on to get us there.
Posted Jul 10, 2022 5:05 UTC (Sun)
by jonesmz (subscriber, #130234)
[Link] (2 responses)
Every single one of the security benefits claimed by flatpack could be provided by traditional packaging systems like dpkg and rpm as an incremental improvement to those packages.
So why flatpack in the first place, if it comes with all this enormous baggage?
Posted Jul 10, 2022 7:41 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Jul 10, 2022 8:31 UTC (Sun)
by atnot (subscriber, #124910)
[Link]
Sure, but are they doing it? Almost universally no, because this kind of sandboxing for linux GUI applications requires a lot of additional work, metada, code changes and considerations and distros don't see a need. As far as I can tell, Flatpak have been the only ones driving these features. It does happen a bit for system services though thanks to systemd's sandboxing features. But getting every maintainer to turn them on has been hard.
If you want to change that go ahead, it would be great!
> So why flatpack in the first place, if it comes with all this enormous baggage?
The primary goal is to make it easier to target applications at Linux. The biggest demographic of Flatpak developers, afaict, is KDE and GNOME developers who were annoyed by the amount of work required to get your application onto every distro and inability to deliver speedy updates. Isolation and sandboxing are just implementation details to make that less haphazard.
Posted Jul 10, 2022 12:18 UTC (Sun)
by jafd (subscriber, #129642)
[Link]
Learning from the mistakes of the competition is hard. But it’s also vital.
I wouldn’t have anything against distributions just being honest: we adopt and push flatpak on everyone because maintenance of packages is hard and we don’t want to be doing it. Flatpak is also slightly better at removing stuff you don’t need without leftover files. Okay. I can understand that.
This brings us more or less to the level of Windows 7 security where you download all sorts of crap from the internet, and the publisher has the final word.
But offering a sandbox that doesn’t quite protect you, and claiming “hey it’s better than nothing” is vile. It doesn’t provide anything more than a false sense of security. Like a counterfeit bulletproof vest.
Posted Jul 13, 2022 13:36 UTC (Wed)
by grove (guest, #1721)
[Link]
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland