One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when prompted).
We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use. Forcing user interaction at worst raises awareness, at best prevents the privacy of individuals from being invaded.
I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it.
The current strategy seems to be having outsiders packaging all the desktop software in to flatpak while disabling any sandboxing that gets in the way. This brings you to the same state as traditional package managers with little security, but it boosts the flatpak ecosystem and makes it ready for the average person. At that point app devs will be more aware of it and can build their apps to tolerate missing access to things and prompting for access.
If the package has host fs access, the sandbox is essentially turned off. A few packages have this because they just don't work without it. The thing is, clickbait bloggers go nuts over this but the state is not any worse than if you had used a .deb
The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to literally no sandboxing. I am certain this is not an intentional misleading feature because Gnome Software is hardly functional and need serious work across the entire program.
When I install something using dnf for example it installs near-instantaneously! Makes me wonder wtf Gnome Software does in the background to make installs so slow :P
It also just seems sooooo slow. I also drop to the terminal for these tasks 100% of the time - including search. I’ll Google for software, and then dnf search to find the specific package if it’s offered.
> The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to literally no sandboxing.
The current mockups[1] for a UI refresh of GNOME Software have the “Sandboxed” badge and the permission details replaced by a context tile giving an overall “Safe”, “Potentially Unsafe”, or “Unsafe” rating, with additional indications and a safety dialog giving the full information. The ratings are determined from the permissions as well as license, whether the runtime is no longer supported, and whether the source is known.
Why not just fake stuff? If you give software no file permissions, show it an empty dir. Tell the software you saved it's file but don't, just keep it in an memory overlay just for that program's run. If it wanted the network, give it a dummy net.
Easy, show a pop-up informing the user that the application tried to access so and so file, and if this was intentional, please click allow and try again.
When the sandbox works as it should, the application has no idea that so and so file even exists.
The flatpak portals are trusted system components, that work outside the sandbox and can present some choosers, where the user picks what will eventually become accessible inside sandbox, if the user agrees (whether files via file choosers, microphones, cameras, desktop sharing, whatever). The sandboxed processes talks to the these portal via IPC (dbus, normally).
The thing is, that outside of standard gtk3 and qt5 apps, nothing else uses portals yet (and gtk3 with qt5 do that at framework level, so it's transparent for the apps). You cannot sandbox random electron app, for example, and expect that it will work just like it worked when it was installed via deb or rpm. And with files, it is just not single files (document apps are relatively easy), but imagine opening project file inside IDE or playlist inside media player: the project or playlist was picked by the user and can be opened by the app, but it contains references to other files, potentially hundreds of them. Can you imagine asking the user to confirm opening each and every one of the hundreds of files?
And then there were people complaining that their locally installed SDKs cannot be used from sandboxed IDEs. Sigh, that's kind of the point...
As an counterargument, see all the comments to this article.
Most people here comment on something they have exactly zero idea about how the security model works, how the transition (i.e. holes in the sandbox and the reasoning behind them) works and what is the intended end-result (portals).
Very similar. Either complaining about non problems, or complaining about some default they can change, or suggesting solutions that are over-complicated and simultaneously inadequate anyway.
Same underlying reason, except it is worse, because it is in the quadrant "they think they know, and they really don't".
Agreed, the current state is such that many developers either rely on package managers for auto-updates (thus lacks sandboxing anyway) or use Snap (which is usually similarly not sandboxed and you have to put your trust in some proprietary cloud platform to push code to your computer). Just getting devs to support Flatpak is an effort, but once that's done sandboxing can be worked on later.
> The problem is that every desktop program must be rewritten to support this idea
No, and expecting that to work is obviously ridiculous. This type of problem needs to be solved in a way which requires no changes at all from developers, or it will almost certainly go nowhere.
Is not that simple. First you would need a flatpack daemon that manages that permission, that the application could ask for a path (e.g. by writing in a control socket) and the daemon asks the user and mounts that paths inside the container, and then inform the application that the operation is successful. But that would require modifying the application, and not in a trivial way, and it's unacceptable (you need to fork basically every application that you package for flatpack, and the filesystem access could be in various places).
A more acceptable solution would be to intercept all the filesystem related system calls, look if a path is accessible, and if not ask for the permission and either try again the system call and return the result or return to the application E_AGAIN (but is not ideal since not a lot of applications handle that correctly). But this approach would probably require a kernel module, or you can do that with eBPF but obviously you would need CAP_SYS_ADMIN capability so not really possible.
The approach of flatpack is create a container with all the paths that you know the application can access and then jump into the container. A simple solution that even doesn't require a daemon and doesn't require modifying the applications.
It will certainly work for the vast majority that are using #include <stdio.h> and more importantly for the various GUI apps that are using GTK/Qt dialogs.
This is for security, though - you can't just assume it's good enough because it will work for most benign applications - you need to be sure it will work for all applications - benign or malicious!
There are other solutions such as seccomp (as siblings of your post have pointed out) that solve this securely, but LD_PRELOAD won't.
Confirming these settings at first launch is something that mostly annoys users. Remember: Most users just install software via Flatpak because this way they don't have to compile it themselves, deal with a tarball or use an outdated release their distribution ships.
Also, if you want to review or change these settings, you can use Flatseal[0]. Arguably, it should be installed by default.
The problem with flatkill.org is that it leads to users rather downloading a random deb off the internet or an AppImage than using Flatpak, which both have worse security stories.
As it happens, macOS didn’t get away with it for me. It’s the single largest reason I’m moving away from the platform.
On iOS the system works because of the type of tasks I do (and do not) perform on a phone. But when I start an automated Applescript and it pauses partway through with a permissions prompt, that’s a problem.
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 :)
From that perspective, moving to OpenBSD seems mostly pointless as currently the best practice there if file permissions are too strict seems to be "comment out some unveil lines and recompile the program." Not really an improvement IMO.
From that angle if the permission dialogs bothered you then you could just recompile flatpak to unconditionally approve all dialogs. (Maybe there is even a setting for this already?) Of course as a sibling comment has said, this would be pretty dangerous, almost equivalent to using windows without UAC, or sudo with NOPASSWD.
I personally think being able to know what my applications are doing and being able to micromanage software permissions if I need to is beneficial.
In 2021, UNIXen are not as isolated as before. A lot of closed source software is creeping into the ecosystem. I'm not against that, but being able to limit them to sandboxes is a good thing IMHO.
I run VMs for such software, but a lighter weight solution is may prove more useful for some scenarios.
You apparently didn’t read the parent: “ I'm sure the same model can be applied to Linux.” I was replying to that, so perhaps your reply belongs one level up. I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction. I already know of a few packages I depend on which are only officially packaged as snaps - I’ve had to find alternatives or look into compiling from source (not always feasible - I don’t have a ton of time to tinker anymore).
> I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction.
Parent here. Whoa, you're reading too deep into that. How do you think that I envision such a future? Even I didn't know I've envisioned such a future.
If I had time to implement such an elaborate subsystem, I'd do it as a user-configurable kernel level interface. Like a more user-configurable, more flexible version of SELinux or AppArmor.
The first thing I'd implement would be a global on/off switch, too. I've seen and worked in enough projects where keeping it on was the only sensible choice, and I know enough that some people (incl. me in some scenarios) would like to keep it turned off.
For clarity, I neither support snaps, commercialization of Linux distributions to create commercial lock-ins, centralizing packages like Snap and dumbing down Linux. I already don't touch Chrome, Electron, VSCode and other pseudo opensource and pseudo free software and use some paid, cross-platform closed source software since they solve some real problems of mine, but I wouldn't dream of a Linux like you're creating by reading my simple comment.
There is a mechanism for this called portals (1) available in flatpak. It gets integrated into the GUI toolkit, and certain applications are not supported. It is useful for things like accessing files from outside the default sandbox.
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 permission only for that file for a limited time e.g. only to read it once.
Also there is no easy way to know what these apps send over network. How do I know they are not downloading all my documents to China?
If it's anything like on Android, where you just give it blank permission to access your entire storage, it would be useless. There are plenty of programs you might want to use that have no business having access to everything, that you can't or don't want to trust 100%, but it's easier for the developers just to ask for everything (or it's the only option).
The "ask for permission" model is broken.
Everything should be sandboxed without giving the application awareness of being sandboxed. If you want to give additional access to a program, it should be through an external interface only accessible to the user.
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 or something.
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.
IMO we need a new runtime OS/system library for it. People have commented here that LD_PRELOAD wouldn't work so I suppose we need a software with which you can force a program to only see the libc.so you want it to see -- as a start.
Bringing in a new programming language might be valuable for it in the future but at least off the top of my head I can't see why can't this model be adapted relatively easily in most languages today.
Because what we need to be expressing - and it would be better at a language level however that's done: is something that can be introspected reliably by the OS at runtime to create assurances about how data is used in the system.
We shouldn't need to put data in and then trust it doesn't somehow wind up being sent over the internet - we should be able to prove this before we put it in.
The system needed is something like SELinux for programs - data goes in and gets tagged that it's there, and before we do that whatever the trusted OS is prompting us for permissions for, it's actually proving the application will do.
Obviously this might not be a new language: abstracting out how files are used so applications go through trusted interfaces to do things is probably the better solution but the key is starting at user data first and being able to make positive assertions about what can't happen (in the absence of bugs in the enforcement mechanism obviously): i.e. "these personal photos can only be viewed by me, and be sent encrypted over the network to these classes of recipient encryption key" should be a reasonable policy statement we can enforce without needing to explicitly grant permissions to every app which wants to do something with photos.
If we can prove at runtime the app can't or won't be able violate policy, then we don't need to keep throwing "do you want to allow?" dialogs in the user's face and pretend we've done something useful for their security.
To my mind this ultimately requires us to have a runtime framework for tracking data provenance and entropy for what we feed into the system: at any given time we want the OS to have a good idea of where any set of data in an application came from, and how much entropy has been increased by transforms against it (i.e. taking the length of a file doesn't leak much data about it, but letting that be an unmitigated side-channel would be worse).
For example: the operation the user doesn't need to see is "this application is syncing your photos to your Google account". The operation they should be prompted for is "this application dumped a whole lot of data into a function we don't recognize, and the output data which we can see is tagged as possibly containing your photos, it now wants to send to this unknown IP address".
This is probably quite hard to implement without modifying the packaged applications. Needs something like a mechanism of pausing, instead of denying, a system call in the kernel and calling back to userspace, which would then load new policy into the ruleset on the fly and resume execution. Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.
Maybe some antivirus etc products manage to seemingly do things like this on Windows platforms, but they have generous support from the platform developed over decades, are executing custom 3rd party kernel drivers, are unhindered by opinionated kernel developers blocking the feature due to their distaste for these hacks, and the resulting system is still unsound and rife with stuff like TOCTOU vulnerabilities, and the prompts are not intelligible to nontechnical users.
Doesn't this imply that Linux is falling behind somewhat in the area of permissions management? Personally, i think that limiting access to files and such based on users and groups simply isn't enough and instead the user should be prompted (or should be able to configure) which piece of software is allowed to do what (network access, file system access, talking to specific devices) based on their own individual needs.
> Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.
I don't believe that this is such a big problem, since Android is pretty explicit about this - a camera app asking for access to my contacts will simply get denied and will promptly be uninstalled.
Depends on your POV I guess, whether you think this model is a worthy one. Personally I think we'd be better off building simpler and more understandable compartmentalization.
Re Android, it was designed from the ground up for this (the camera app request is even called "Intent"). So it's not really solving the question of running unmodified applications.
Isn't this something that was addressed already years ago by SELinux, even before Android? Personally I prefer to not use it since I don't find it very user friendly but Fedora seems to have it activated by default.
Android only uses the Linux kernel, everything else is completly unrelated to GNU/Linux, besides the lockdown enforced via LinuxSE and seccomp, so Google could naturally make this kind of customization.
In some cases it does request permissions when you try to do things. E.g. sandboxed apps without full filesystem access can open & save files through a 'portal' - the system presents the user with an open/save dialog, and the app gets access to the file or folder they select. Things like screen sharing can work similarly - the system asks the user to approve access for the app.
But, as other people have said, this involves new APIs. In the open/save case, the app has to request that the system display a file chooser instead of drawing its own. GTK & Qt can hide this change so apps built on those toolkits benefit automatically. But beyond really self-contained things (like games) most apps that haven't been developed with a sandbox need some adjustment to play nicely within a sandbox. And making changes depends on building a consensus that it's worth doing.
> One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used?
The POSIX APIs do not have such permissions. You can attempt to put something in between and have lots of stuff break, that's what Apple did. On Linux, there is no such authority.
There are alternatives as well, such as sandboxing all the way up to using a hypervisor for every program, which is arguably what you need to run an untrusted program.
> We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use.
Fair enough, but Flatpaks are mostly open-source software and closed-source software can be monitored far better on a Linux system.
Because the system can't be intelligent enough for that.
Say the process wish to write to a particular file; — how far up the directory tree does the system ask for permission?; only that specific path? the home directory?; how can the system know this?
Of course, the other issue is that, say the system be implemented so that the write call blocks until the permission be given, that they will timeout with an error because they have limits on write calls that take that long, and assume there is something else that is wrong like mechanical storage failure, if a simple write call truly take seconds.
Simplistic response: Apple & Google (A&G) don't want people concerned with what's going on under the hood. It is difficult to explain. Also, imagine that you download something, you pay for it, then it asks a question you do not understand (rights 666 or 777? - what the hell? I don't want the devil on my phone!! NO to 666, Yes to 777)(maybe I will win in the casino). And assumming you 'Deny' and the app doesn't work. And you paid $10 for it. You uninstall, reinstall, and 'Allow'.
(Majority of) People barely understand the (privacy/security) impact of giving access to Location, Contacts, Calendar, Phone, SMS. Now think of the more obscure (?) layers of the following pyramid: Hardware, Middleware/Drivers, OS, Applications. (Majority of) People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!
Although both A&G can review your code and flag these upfront with some auto-policy-check, I feel that it would send many app creators reeling & pain. Pain for app creators = smaller revenue to A&G.
I assume it's the typical cat & mouse game. A&G may try to reduce/prevent access here but their SDKs will create a new oppotrunity/workaround to get access there. The new "there" access will be abused and someone will find away to do what they were doing in the previous setup. And thus we restart the chase.
It's in the way that people code. Naughty and/or lazy coders will go for the keys to the kingdom, ignoring the security. To avoid misunderstanding the word 'lazy' doesn't mean 'lazy people', but 'lazy/inapprpriate/corner-cutting practices'.
> People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!
Well this is how it works in OSX (“Would you like to grant this application permissions to this folder?”), so I guess the answer is “yes - that’s exactly what Apple do”.
Reminds me of some bizarro Android permission issues, when I wanted to install a TLS client certificate (pfx) file. I downloaded it via web browser to a phone, opened the certificate management app, and the file was grayed out, no explanation, nada. No way to click on it, no error messages, no confusing permission flags in the file list. I thought the format of the file was wrong, so I tried regenerating it a few times in different formats, wasting an hour or two.
Turns out, you have to copy the file to some folder via adb command line, to make it usable by Android. Copying directly to a uSD card would have probably worked too, but how many people just have a uSD card reader lying around.
But I didn't get a confusing security prompt when downloading from a https:// url, that I might not have understood, so I was better off I guess. /s
We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use. Forcing user interaction at worst raises awareness, at best prevents the privacy of individuals from being invaded.