7 ms·

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

by dastx 5y ago

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.

foobar33333 5y ago
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.
- Iolaum 5y ago
  > This brings you to the same state as traditional package managers with little security Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.
  - foobar33333 5y ago
    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.
    - tored 5y ago
      Gnome Software is pretty much unusable for installing software. 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.
      - gbrown 5y ago
        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.
      - uneekname 5y ago
        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
    - antimba 5y ago
      > 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. [1]: https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw/master/adaptive/context-tiles.png https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw...
  - syrrim 5y ago
    That's what he's saying
- fragileone 5y ago
  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.
- lambda_obrien 5y ago
  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.
  - vetinari 5y ago
    And then have a barrage of users complaining that their app packaged in flatpak doesn't work.
    - Shared404 5y ago
      Perhaps make it an optional setting? "Enhanced Sandboxing (Warning: This feature is experimental, and may cause issues for some apps.)" or something of the sort.
      - vetinari 5y ago
        It is... you can add/remove any paths you like. The default errs into what users are used to. See also threads bellow; people complaining that the Signal client can save only into ~/Downloads.
        Shared404 5y ago
        Makes sense. I use flatpaks only very lightly, I apologize for not checking before opening my mouth :)
        vetinari 5y ago
        Opening the mouth is fine, nobody has fallen from the sky fully learned about everything ;). If you learned something that is interesting or useful to you, then great.
    - tjoff 5y ago
      Users are stupid, but they are not as stupid to press no on a request to allow an application to open files and then complain that no files exist.
- epr 5y ago
  > 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.
fulafel 5y ago
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.
- KronisLV 5y ago
  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.
  - fulafel 5y ago
    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.
  - blablabla123 5y ago
    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.
harporoeder 5y ago
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. 1. https://docs.flatpak.org/en/latest/portal-api-reference.html https://docs.flatpak.org/en/latest/portal-api-reference.html
- its-summertime 5y ago
  specifically, anything that uses the generic GTK/Qt way of accessing files via the file chooser will automagically use the portal Anything that tweaks on that, most notably Electron, will not use the portal
  - akvadrako 5y ago
    That's a choice of Electron - it could and should use portals.
gigatexal 5y ago
How better or worse is Flatpak than a chmod +x’d AppImage?
linmob 5y ago
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. [0] https://github.com/tchx84/Flatseal https://github.com/tchx84/Flatseal
- bayindirh 5y ago
  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.
  - loloquwowndueo 5y ago
    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 :)
    - bayindirh 5y ago
      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.
    - cycloptic 5y ago
      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.
alerighi 5y ago
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.
- ddtaylor 5y ago
  > But that would require modifying the application Technically it can be done using LD_PRELOAD on fopen() and such.
  - maffydub 5y ago
    Can it? If my application invokes syscalls directly, that wouldn't hit anything interposed using LD_PRELOAD.
    - ddtaylor 5y ago
      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.
      - maffydub 5y ago
incrudible 5y ago
> 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.
HenryBemis 5y ago
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'.
- Closi 5y ago
  > 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”.
- megous 5y ago
  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:// https:// url, that I might not have understood, so I was better off I guess. /s
varispeed 5y ago
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?
- XorNot 5y ago
  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.
  - Daho0n 5y ago
    Why do you want a new language for this?
    - XorNot 5y ago
      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".
Blikkentrekker 5y ago
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.
rathboma 5y ago
As a desktop app developer this is what I need. 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
takluyver 5y ago
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.

by dastx 5y ago

foobar33333 5y ago

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.

Iolaum 5y ago
> This brings you to the same state as traditional package managers with little security Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.
- foobar33333 5y ago
  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.
  - tored 5y ago
    Gnome Software is pretty much unusable for installing software. 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.
    - gbrown 5y ago
      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.
    - uneekname 5y ago
      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
  - antimba 5y ago
    > 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. [1]: https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw/master/adaptive/context-tiles.png https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw...
- syrrim 5y ago
  That's what he's saying
fragileone 5y ago
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.
lambda_obrien 5y ago
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.
- vetinari 5y ago
  And then have a barrage of users complaining that their app packaged in flatpak doesn't work.
  - Shared404 5y ago
    Perhaps make it an optional setting? "Enhanced Sandboxing (Warning: This feature is experimental, and may cause issues for some apps.)" or something of the sort.
    - vetinari 5y ago
      It is... you can add/remove any paths you like. The default errs into what users are used to. See also threads bellow; people complaining that the Signal client can save only into ~/Downloads.
      - Shared404 5y ago
        Makes sense. I use flatpaks only very lightly, I apologize for not checking before opening my mouth :)
        vetinari 5y ago
        Opening the mouth is fine, nobody has fallen from the sky fully learned about everything ;). If you learned something that is interesting or useful to you, then great.
  - tjoff 5y ago
    Users are stupid, but they are not as stupid to press no on a request to allow an application to open files and then complain that no files exist.
epr 5y ago
> 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.

fulafel 5y ago

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.

KronisLV 5y ago
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.
- fulafel 5y ago
  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.
- blablabla123 5y ago
  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.

harporoeder 5y ago

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. 1. https://docs.flatpak.org/en/latest/portal-api-reference.html https://docs.flatpak.org/en/latest/portal-api-reference.html

its-summertime 5y ago
specifically, anything that uses the generic GTK/Qt way of accessing files via the file chooser will automagically use the portal Anything that tweaks on that, most notably Electron, will not use the portal
- akvadrako 5y ago
  That's a choice of Electron - it could and should use portals.

gigatexal 5y ago

How better or worse is Flatpak than a chmod +x’d AppImage?

linmob 5y ago

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. [0] https://github.com/tchx84/Flatseal https://github.com/tchx84/Flatseal

bayindirh 5y ago
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.
- loloquwowndueo 5y ago
  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 :)
  - bayindirh 5y ago
    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.
  - cycloptic 5y ago
    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.

alerighi 5y ago

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.

ddtaylor 5y ago
> But that would require modifying the application Technically it can be done using LD_PRELOAD on fopen() and such.
- maffydub 5y ago
  Can it? If my application invokes syscalls directly, that wouldn't hit anything interposed using LD_PRELOAD.
  - ddtaylor 5y ago
    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.
    - maffydub 5y ago

incrudible 5y ago

> 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.

HenryBemis 5y ago

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'.

Closi 5y ago
> 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”.
megous 5y ago
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:// https:// url, that I might not have understood, so I was better off I guess. /s

varispeed 5y ago

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?

XorNot 5y ago
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.
- Daho0n 5y ago
  Why do you want a new language for this?
  - XorNot 5y ago
    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".

Blikkentrekker 5y ago

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.

rathboma 5y ago

As a desktop app developer this is what I need. 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

takluyver 5y ago

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.