11 ms·

All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case

by nodja 6y ago

All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?

littlestymaar 6y ago
Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?
- mavhc 6y ago
  Passing responsibility of not distributing evil software from the gatekeepers to the user. Ignores half the point of having a distribution that has a package manager, curated software.
  - oblio 6y ago
    So the solution is to have the package manager decide things for every user?
    - diffeomorphism 6y ago
      Yes, the point is to have the package manager set sane defaults for every user. Say you distribute a video app. It is completely counterproductive to have every user click on a permission dialog "I allow this video app to open videos". This only trains users to blindly allow everything to make software, you know, work at all. A much more sane approach would be to enable access to ~/videos and other reasonable places at install time and only ask for additional permission when needed.
      - lokedhs 6y ago
        Flatpak allows this, but requires changers to the application so that it calls the correct API's when requesting files outside of the allowed directories. The article does highlight some actual issues, but the author implies that the solution is to simply not use it at all and go back to the free for all smörgåsbord of access rights that an application installed from the regular repositories have. Personally, I consider Flatpak the best solution available right now time minimise the attack surface for anyone not willing yo go all the way and run Qubes OS. If there is a better alternative I'd be happy to hear it, since I cannot run Qubes one of my machines.
  - hnedeotes 6y ago
    Why can't they be complementary?
    - eeZah7Ux 6y ago
      Because distributions don't need flatpak. There are already methods to do sandboxing like systemd and firejail.
      - hnedeotes 6y ago
        Ah sure, I was referring to the: > Passing responsibility of not distributing evil software from the gatekeepers to the user. As in, we can have gatekeepers but also force software to define explicit access policies. Like, maybe a program that needs regularly files will create a folder where they have access to files and any files placed there afterwards can be used by the program without asking for access. For all other files/folders it would ask for specific access, and the access could be given as session based or normal and apply to the selected files only? Having a default folder (per application) could then be used by programs like word processors or wtv to have a place to save automatically so the ux doesn't suffer in the basic case. Saving files outside authorised folders would not need permission unless they were overwriting a file that wasn't permitted previously, but access to other things in a non permitted folder would require permission still? This could live with existing package managers curation and sandboxing, but even if the programs somehow got into a compromised state they would be limited?
        mavhc 6y ago
        What's the point though? Either the software is evil/has a bug that lets it steal all your data, or it doesn't. Making each app have its own filesystem just forces a weird file structure where you don't have a folder for a project, but for an app. Whose projects only consist of one type of files? If the app is a web browser then fair enough, but what other apps would that be useful for?
        hnedeotes 6y ago
  - foobar33333 6y ago
    Flatpak is a package manager which supports repos exactly like traditional package managers. The biggest repo is flathub and there is also one for fedora which is a little more vetted but contains less software.
- diffeomorphism 6y ago
  In practice this has the same effect as windows vista had. You train users to immediately click away the annoying popups without reading them.
  - darkwater 6y ago
    Or any Android/iOS users (which is perfectly normal, people want to use the app, not being constantly vigilant of not being pwned)
josefx 6y ago
> All of the examples are apps where the main use is manipulating files on the system. So do users, still can't overwrite system wide settings without first getting root. Decent sand boxing has to be granular enough to cover partial access. Of course the hard part on Linux would be locking access to files like ~/.bashrc without completely blocking access to the home directory, that probably would require an exhaustive list of all config files that are directly stored in home instead of a specialized sub folder.
- foobar33333 6y ago
  Flatpak apps can not access root owned files. They run as the user and the typical linux permissions apply. They can only gain access to root if they have filesystem access so they can load malware in to bashrc. The thing is this is exactly the same as traditional packaged linux software. Flatpak only offers the ability for extra security.
  - josefx 6y ago
    > Flatpak apps can not access root owned files. I think I didn't make my point clear. I used that as an example of "needs to access files" not meaning "needs to access all files, including but not limited to configuration files". > Flatpak only offers the ability for extra security. With a permission model that apparently can't keep an image editing application from silently editing .bashrc .
    - foobar33333 6y ago
      >With a permission model that apparently can't keep an image editing application from silently editing .bashrc . It can, you can cut off all filesystem access or select certain areas. The problem is that programs often need special attention to make sure they work properly using flatpak portals. Currently not many devs are interested in doing this work since flatpak is pretty small right now. So for now we must assume that Gimp built from the official source, is not a malicious program. Like we have for the last 25 years.
kelnos 6y ago
The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user. This does mean that some apps potentially do have worse UX; any app that implements a custom file picker will just stop working properly. Arguably in that case you just simply cannot sandbox that kind of app, and you shouldn't try, because it gives people a false sense of security in using it. For apps that want to do custom things you essentially have to make them not need to do custom things by building their custom behavior into the sandbox-owned file picker (or whatever), and allow them to make use of it in a safe way. But that's a lot of work, and it doesn't seem like the Flatpak folks really work with the toolkit authors.
- foobar33333 6y ago
  >The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user. Flatpak has this already. They call it portals and it covers more than just file pickers. The problem I have seen is that shoving existing software in to flatpaks and making them use portals ends up buggy for unknown reasons. I think the app devs themselves need to make at least some conscious effort to make sure it works and not directly access files.
  - necovek 6y ago
    > ends up buggy for unknown reasons I think the reasons are quite clear: introducing asynchronicity (one requiring further user interaction at that) into what used to be synchronous code is one of the most common ways to introduce bugs. App devs would be right to sit tight and see who gets a higher market share (snaps/flatpak) before implementing any of the proprietary approaches they might employ. Apps which do implement them probably have an investment in the ecosystem already (eg. Canonical-developed apps will make use of Snap APIs, whereas Red Hat-developed apps will make use of Flatpak APIs). This will however suck for end users because now software starts depending on packaging :/
    - 6y ago

by nodja 6y ago

All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?

littlestymaar 6y ago

Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?

mavhc 6y ago
Passing responsibility of not distributing evil software from the gatekeepers to the user. Ignores half the point of having a distribution that has a package manager, curated software.
- oblio 6y ago
  So the solution is to have the package manager decide things for every user?
  - diffeomorphism 6y ago
    Yes, the point is to have the package manager set sane defaults for every user. Say you distribute a video app. It is completely counterproductive to have every user click on a permission dialog "I allow this video app to open videos". This only trains users to blindly allow everything to make software, you know, work at all. A much more sane approach would be to enable access to ~/videos and other reasonable places at install time and only ask for additional permission when needed.
    - lokedhs 6y ago
      Flatpak allows this, but requires changers to the application so that it calls the correct API's when requesting files outside of the allowed directories. The article does highlight some actual issues, but the author implies that the solution is to simply not use it at all and go back to the free for all smörgåsbord of access rights that an application installed from the regular repositories have. Personally, I consider Flatpak the best solution available right now time minimise the attack surface for anyone not willing yo go all the way and run Qubes OS. If there is a better alternative I'd be happy to hear it, since I cannot run Qubes one of my machines.
- hnedeotes 6y ago
  Why can't they be complementary?
  - eeZah7Ux 6y ago
    Because distributions don't need flatpak. There are already methods to do sandboxing like systemd and firejail.
    - hnedeotes 6y ago
      Ah sure, I was referring to the: > Passing responsibility of not distributing evil software from the gatekeepers to the user. As in, we can have gatekeepers but also force software to define explicit access policies. Like, maybe a program that needs regularly files will create a folder where they have access to files and any files placed there afterwards can be used by the program without asking for access. For all other files/folders it would ask for specific access, and the access could be given as session based or normal and apply to the selected files only? Having a default folder (per application) could then be used by programs like word processors or wtv to have a place to save automatically so the ux doesn't suffer in the basic case. Saving files outside authorised folders would not need permission unless they were overwriting a file that wasn't permitted previously, but access to other things in a non permitted folder would require permission still? This could live with existing package managers curation and sandboxing, but even if the programs somehow got into a compromised state they would be limited?
      - mavhc 6y ago
        What's the point though? Either the software is evil/has a bug that lets it steal all your data, or it doesn't. Making each app have its own filesystem just forces a weird file structure where you don't have a folder for a project, but for an app. Whose projects only consist of one type of files? If the app is a web browser then fair enough, but what other apps would that be useful for?
        hnedeotes 6y ago
- foobar33333 6y ago
  Flatpak is a package manager which supports repos exactly like traditional package managers. The biggest repo is flathub and there is also one for fedora which is a little more vetted but contains less software.
diffeomorphism 6y ago
In practice this has the same effect as windows vista had. You train users to immediately click away the annoying popups without reading them.
- darkwater 6y ago
  Or any Android/iOS users (which is perfectly normal, people want to use the app, not being constantly vigilant of not being pwned)

josefx 6y ago

> All of the examples are apps where the main use is manipulating files on the system. So do users, still can't overwrite system wide settings without first getting root. Decent sand boxing has to be granular enough to cover partial access. Of course the hard part on Linux would be locking access to files like ~/.bashrc without completely blocking access to the home directory, that probably would require an exhaustive list of all config files that are directly stored in home instead of a specialized sub folder.

foobar33333 6y ago
Flatpak apps can not access root owned files. They run as the user and the typical linux permissions apply. They can only gain access to root if they have filesystem access so they can load malware in to bashrc. The thing is this is exactly the same as traditional packaged linux software. Flatpak only offers the ability for extra security.
- josefx 6y ago
  > Flatpak apps can not access root owned files. I think I didn't make my point clear. I used that as an example of "needs to access files" not meaning "needs to access all files, including but not limited to configuration files". > Flatpak only offers the ability for extra security. With a permission model that apparently can't keep an image editing application from silently editing .bashrc .
  - foobar33333 6y ago
    >With a permission model that apparently can't keep an image editing application from silently editing .bashrc . It can, you can cut off all filesystem access or select certain areas. The problem is that programs often need special attention to make sure they work properly using flatpak portals. Currently not many devs are interested in doing this work since flatpak is pretty small right now. So for now we must assume that Gimp built from the official source, is not a malicious program. Like we have for the last 25 years.

kelnos 6y ago

The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user. This does mean that some apps potentially do have worse UX; any app that implements a custom file picker will just stop working properly. Arguably in that case you just simply cannot sandbox that kind of app, and you shouldn't try, because it gives people a false sense of security in using it. For apps that want to do custom things you essentially have to make them not need to do custom things by building their custom behavior into the sandbox-owned file picker (or whatever), and allow them to make use of it in a safe way. But that's a lot of work, and it doesn't seem like the Flatpak folks really work with the toolkit authors.

foobar33333 6y ago
>The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user. Flatpak has this already. They call it portals and it covers more than just file pickers. The problem I have seen is that shoving existing software in to flatpaks and making them use portals ends up buggy for unknown reasons. I think the app devs themselves need to make at least some conscious effort to make sure it works and not directly access files.
- necovek 6y ago
  > ends up buggy for unknown reasons I think the reasons are quite clear: introducing asynchronicity (one requiring further user interaction at that) into what used to be synchronous code is one of the most common ways to introduce bugs. App devs would be right to sit tight and see who gets a higher market share (snaps/flatpak) before implementing any of the proprietary approaches they might employ. Apps which do implement them probably have an investment in the ecosystem already (eg. Canonical-developed apps will make use of Snap APIs, whereas Red Hat-developed apps will make use of Flatpak APIs). This will however suck for end users because now software starts depending on packaging :/
  - 6y ago