7 ms·

“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.

by yzmtf2008 8y ago

untog 8y ago
It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.
- yzmtf2008 8y ago
  macOS does this via the open dialog — opening a directory gives an application full access to that directory
  - m45t3r 8y ago
    And you can have the same issue the author said in the article by requesting access to home directory and running the exactly the same command as the author wrote.
    - int_19h 8y ago
      You'd need to open your entire home dir for that. In VSCode, you normally open the specific directory that contains the source for one particular project you're working on, so in that model, it would only be granted permission to that directory.
- voltagex_ 8y ago
  Virtualised paths with specific access - i.e. VS Code would only see one path.
- pcwalton 8y ago
  Same way it works on the web: Use a broker process that grants access via a file select dialog.
  - vetinari 8y ago
    The point is, that for vscode picking a file is not enough. It would cause lot of fun opening multi-root workspaces you just checked out... There are many more applications, not just IDEs, where picking a file or folder is not sufficient: for example, apps like Rapid Photo Downloader or Darktable would be significantly crippled.
viraptor 8y ago
It depends on your use case. If you sandbox tar (for example), you'd do it be removing all network access and a few fancy caps, but you'd leave the rw access to the whole system. (within its standard privileges) If you sandbox netcat, you'd do the opposite: remove all fs access (unless you care about pipes) and leave open networking. There's nothing about the idea of a sandbox that requires a specific approach.
- voltagex_ 8y ago
  Have a look at AppV on Windows. It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home.
  - AnthonyMouse 8y ago
    > It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home. Then how do you get it to operate on your actual home directory when you want it to? Making it operate on some different structure has been possible with chroot() or LVM snapshots or a number of other things for a long time.
    - comex 8y ago
      Well, Flatpak is designed for GUI applications, where the user indicates their intent to grant access to a file by picking it the file chooser (which is magic, runs outside the sandbox, and grants the sandbox access to whatever file the user picked). This is nice because the sandbox can be invisible from the user’s perspective. I think AppV is similar. For a CLI application like tar, this would be a bit harder because every program has its own command line syntax and you can’t always tell what arguments are supposed to be filenames. Still, you can do reasonably well by just granting access to any argument that looks like a filename. The Plash shell, a forerunner of modern sandbox designs, took this approach, but as an additional security measure only granted read access by default; if you wanted to run a command that writes to a file, you had to use special syntax before the filename [1]. Still reasonably usable, although there are other issues, like the fact that many Unix programs default to reading and/or writing to the current directory… [1] http://www.cs.jhu.edu/~seaborn/plash/html/shell.html#shell-diffs http://www.cs.jhu.edu/~seaborn/plash/html/shell.html#shell-d...
michaelmrose 8y ago
Nobody wants a packaging system that can't package existing apps not designed to be secure in a useful fashion. In a traditional app packaged as a deb/rpm the developer releases the source which then must be packaged and made to work with each distribution/platform. If the app is malicious or is sold to someone/compromised by someone who is then you are 100% hosed. In a flatpak not designed to be properly sandboxed you are in fact no worse off than the alternative deb/rpm situation save that the issue of packing for distribution has been made easier. It's in fact probably extremely challenging to package all sorts of applications without giving the user the option to provide an individual app elevated permissions. At best we are relying on the user to decide which app ought to get those permissions. If you think people can't be trusted to do this then the logical solution is to rely on packagers to decide what belongs in the official repo and keep malicious content out.
- yellowapple 8y ago
  In flatpak you are worse off, though, since - as the article indicates - they lag behind on security updates. If they get compromised by unpatched exploits, that sandbox is a valuable line of defense.
  - danilocesar 8y ago
    The writer tries to blame Flatpak for app maintainers mistakes. That isn't fair. If an app doesn't get an security fix whoever maintains that package should be the one to blame. Disclaimer: I don't like flatpak either, I'm just trying to be fair here...
    - michaelmrose 8y ago
      This is a fair point. Tons of people said that flatpaks wont get security updates because you would end up with 7 versions of libfoo getting updated, or not, on different schedules. Lo and Behold this is true. The security gains even in the future are also probably mostly imaginary. You can't trust average users to understand the implications of granting permissions. By default if they are installing an app they trust the dev. Further its not like malicious actors can't test against the sandbox and do the extra work to discover ways through the fence. Getting your target to run your malware tends to be game over outside of very heavily restricted environments. If the browser had a build in fashion to ask the user to give them full control of the machine in a way that didn't look like malware 20% of users would end up with compromised devices.

“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.

untog 8y ago

It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.

yzmtf2008 8y ago
macOS does this via the open dialog — opening a directory gives an application full access to that directory
- m45t3r 8y ago
  And you can have the same issue the author said in the article by requesting access to home directory and running the exactly the same command as the author wrote.
  - int_19h 8y ago
    You'd need to open your entire home dir for that. In VSCode, you normally open the specific directory that contains the source for one particular project you're working on, so in that model, it would only be granted permission to that directory.
voltagex_ 8y ago
Virtualised paths with specific access - i.e. VS Code would only see one path.
pcwalton 8y ago
Same way it works on the web: Use a broker process that grants access via a file select dialog.
- vetinari 8y ago
  The point is, that for vscode picking a file is not enough. It would cause lot of fun opening multi-root workspaces you just checked out... There are many more applications, not just IDEs, where picking a file or folder is not sufficient: for example, apps like Rapid Photo Downloader or Darktable would be significantly crippled.

viraptor 8y ago

It depends on your use case. If you sandbox tar (for example), you'd do it be removing all network access and a few fancy caps, but you'd leave the rw access to the whole system. (within its standard privileges) If you sandbox netcat, you'd do the opposite: remove all fs access (unless you care about pipes) and leave open networking. There's nothing about the idea of a sandbox that requires a specific approach.

voltagex_ 8y ago
Have a look at AppV on Windows. It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home.
- AnthonyMouse 8y ago
  > It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home. Then how do you get it to operate on your actual home directory when you want it to? Making it operate on some different structure has been possible with chroot() or LVM snapshots or a number of other things for a long time.
  - comex 8y ago
    Well, Flatpak is designed for GUI applications, where the user indicates their intent to grant access to a file by picking it the file chooser (which is magic, runs outside the sandbox, and grants the sandbox access to whatever file the user picked). This is nice because the sandbox can be invisible from the user’s perspective. I think AppV is similar. For a CLI application like tar, this would be a bit harder because every program has its own command line syntax and you can’t always tell what arguments are supposed to be filenames. Still, you can do reasonably well by just granting access to any argument that looks like a filename. The Plash shell, a forerunner of modern sandbox designs, took this approach, but as an additional security measure only granted read access by default; if you wanted to run a command that writes to a file, you had to use special syntax before the filename [1]. Still reasonably usable, although there are other issues, like the fact that many Unix programs default to reading and/or writing to the current directory… [1] http://www.cs.jhu.edu/~seaborn/plash/html/shell.html#shell-diffs http://www.cs.jhu.edu/~seaborn/plash/html/shell.html#shell-d...

michaelmrose 8y ago

Nobody wants a packaging system that can't package existing apps not designed to be secure in a useful fashion. In a traditional app packaged as a deb/rpm the developer releases the source which then must be packaged and made to work with each distribution/platform. If the app is malicious or is sold to someone/compromised by someone who is then you are 100% hosed. In a flatpak not designed to be properly sandboxed you are in fact no worse off than the alternative deb/rpm situation save that the issue of packing for distribution has been made easier. It's in fact probably extremely challenging to package all sorts of applications without giving the user the option to provide an individual app elevated permissions. At best we are relying on the user to decide which app ought to get those permissions. If you think people can't be trusted to do this then the logical solution is to rely on packagers to decide what belongs in the official repo and keep malicious content out.

yellowapple 8y ago
In flatpak you are worse off, though, since - as the article indicates - they lag behind on security updates. If they get compromised by unpatched exploits, that sandbox is a valuable line of defense.
- danilocesar 8y ago
  The writer tries to blame Flatpak for app maintainers mistakes. That isn't fair. If an app doesn't get an security fix whoever maintains that package should be the one to blame. Disclaimer: I don't like flatpak either, I'm just trying to be fair here...
  - michaelmrose 8y ago
    This is a fair point. Tons of people said that flatpaks wont get security updates because you would end up with 7 versions of libfoo getting updated, or not, on different schedules. Lo and Behold this is true. The security gains even in the future are also probably mostly imaginary. You can't trust average users to understand the implications of granting permissions. By default if they are installing an app they trust the dev. Further its not like malicious actors can't test against the sandbox and do the extra work to discover ways through the fence. Getting your target to run your malware tends to be game over outside of very heavily restricted environments. If the browser had a build in fashion to ask the user to give them full control of the machine in a way that didn't look like malware 20% of users would end up with compromised devices.