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.
Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.
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.
I use it to find software and read reviews, but never install. I always use the terminal for that.
1. Gnome Software does not tell what the package name is for deb, flatpaks, snaps etc
2. Gnome Software does not say what type of package it is (deb, flatpak, snap etc) except when it’s multiple choice.
3. No overview of dependencies.
4. No information what is happening during install.
5. Buggy installation, common case, click on Install, nothing happens, click on Install again and get warning “hey it is already installing you fool!"
Not everyone is comfortable to use the terminal, fixing Gnome Software should be a high priority for distros.
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.
[1]: https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw...
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...
"Enhanced Sandboxing (Warning: This feature is experimental, and may cause issues for some apps.)" or something of the sort.
See also threads bellow; people complaining that the Signal client can save only into ~/Downloads.
If you learned something that is interesting or useful to you, then great.
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).
Same underlying reason, except it is worse, because it is in the quadrant "they think they know, and they really don't".
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.
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.
Technically it can be done using LD_PRELOAD on fopen() and such.
If my application invokes syscalls directly, that wouldn't hit anything interposed using LD_PRELOAD.
There are other solutions such as seccomp (as siblings of your post have pointed out) that solve this securely, but LD_PRELOAD won't.
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.
The annoyance doesn't come from the security, it's from un-refined UX.
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.
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.
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.
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.
Wow.
And a good chunk of those people often would be just fine with that "outdated" version.
1. https://docs.flatpak.org/en/latest/portal-api-reference.html
Anything that tweaks on that, most notably Electron, will not use the portal
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.
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.
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.
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".
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.
> 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.
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.
This happened years ago. Linux is way behind.
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.
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.
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.
I publish a snap variation and so many edge cases break the security system and make the app unusable.
Home perms? What if the user symlinks something into their home directory? Etc
(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'.
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”.
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.