7 ms·

Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, S

Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ... With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action causes a prompt. Now, that's not to say this is good as it is, but for most listed programs it's probably the way to go.

blattimwind 8y ago
File picker is privileged and mediates access through monitor. Ditto for drag-and-drop. Problem (largely) solved.
- aaaaaaaaaab 8y ago
  That’s how macOS sandboxing works too.
- TeMPOraL 8y ago
  Do you open your files in PyCharm or VSCode through a file picker?
  - blattimwind 8y ago
    Drag and drop project folder. Also, yes, I do open project directories using PyCharm's (poor) file picker.
  - stephenr 8y ago
    I’d imagine once you open a directory you can open files within it (and child dirs)
  - ReverseCold 8y ago
    You open the parent project directory, right? That's how the file access controls work in MacOS. Sandboxed apps can't read files outside their sandbox until the user opens the directory/file in the file picker at least once. (Or something similar, I can't seem to find a source on that...)
    - TeMPOraL 8y ago
      Ah, ok. Makes more sense this way.
deleted 8y ago
[deleted]
gmueckl 8y ago
This highlights a conceptual dilemma with access rights in file systems: if an image manipulation software wants to open .bashrc, this is potentially suspicious. But for a text editor this is probably ok. Likewise, a text editor that reads a binary executable is probably a little bit fishy. But a unzip program might so that for a valid reason (e.g. ZIP archive appended at end of program, a common thing for installers). How can we distinguish between those cases?
- briffle 8y ago
  This is pretty much the whole point of SELinux (and probably AppArmour)
  - geofft 8y ago
    How does SELinux or AppArmor distinguish between those cases? More interestingly, how can it tell that VSCode spontaneously editing .bashrc is bad, but doing so in response to user input is good? (There are capability-based systems that permit distinguishing between these cases, but to my knowledge SELinux and AppArmor don't support this.)
    - Conan_Kudo 8y ago
      SELinux labels users and domain transitions, so it's "technically" possible to do so, but I see that incredibly rarely. I don't think AppArmor has such a facility. It wouldn't make sense, given that AppArmor doesn't know these things like SELinux would.
    - cyphar 8y ago
      SELinux and AppArmor would allow you to specify that your text editor is allowed to edit .bashrc, but some random other program isn't. But I agree with you that this is not really a useful security feature -- you'd want something where a program has to be explicitly granted permission rather than some programs being able to do things that others can't (because then any attacker will just spawn "vi -c 'bad payload'" to get around the restriction).
    - 8y ago
AgentME 8y ago
The sandboxing platform could offer an API so a sandboxed program can spawn a privileged file-open dialog, and then the sandboxed program is only allowed to modify the file/directory that the user picked. With the current situation, calling the programs sandboxed is completely misleading.
- audidude 8y ago
  You've described the xdg-desktop-portal. Gtk apps just need to switch to GtkFileChooserNative and they get that for free. It does an FD pass of a FUSE fd and the app never gets file-system access. It also has the benefit of using the KDE file-chooser on KDE, Windows file-chooser on Windows, mac, etc...
vanderZwan 8y ago
Could you link to the comment? Would like to read the discussion on Reddit too.
- ahreflink 8y ago
  https://old.reddit.com/r/linux/comments/9ms96u/flatpak_security_exposed_useless_sandbox/ https://old.reddit.com/r/linux/comments/9ms96u/flatpak_secur...
wongarsu 8y ago
Most use cases of VLC only open files, so giving it universal privileges to open files but a prompt on filesystem writes would be fine. Gimp could have universal read and the right to create new files, but overwriting files it didn't create itself restricted behind a permission prompt. Same for Inkscape and Audacity. If you want to push this further, you could imagine a permission system that can distuingish based on file types. Gimp overwriting a PNG is probably intended, Gimp overwriting a bash script probably not. There's a lot more nuance in existing systems (SELinux) and potential future systems than just "allow everything or nothing".
- faho 8y ago
  Okay, now do emacs! Depending on build-time options, that can open text files, images, pdfs, archives (zip et al). In fact I'm struggling to think of a single file type that truly won't have a use in emacs. (It might actually make more sense to forbid editting executable files than going via type) ----- >There's a lot more nuance in existing systems (SELinux) and potential future systems than just "allow everything or nothing". The problem isn't that there isn't a lot of "nuance" in these systems, the problem is that there is! Sure, SELinux will work if you have a static system or an SELinux expert under the desk. Creating a system that works and remains understandable is much harder.
- int_19h 8y ago
  > but overwriting files it didn't create itself restricted behind a permission prompt It's more nuanced than that. A user might not even have a .bashrc, but you still don't want to allow any random app to create one. In general, it feels like the security model for the FS has to distinguish things that can be executed, and things that cannot. Which it already does on Unix with +x, but then you've got all the scripting languages that cheerfully ignore that, and all the apps that use executable configs etc. If you can fix all those such that +x is required for any source of executable code on the system, then you can just prohibit apps from creating +x files. But the cost of doing that in the existing ecosystem is enormous.
altfredd 8y ago
There is no reason to make it complicated. Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop. I have been using a directory-per-program sandboxing setup for several years (and still do). It is very convenient, and does not require any additional effort to adapt. In fact, I now have less clutter in my actual $HOME than ever before. Programmers like to come up with clever ways to solve nonexisting problems. I say — give user a way to bootstrap a sandboxed environment into a directory of their choice (no, using auto-generated directory names is NOT allowed!), and the "problem" would no longer exist.
- mbreese 8y ago
  I'm sorry, but that solution isn't workable to many (likely a majority of) users. Most will expect that when you open two programs that need to work on the same file, that if you save the file to your $HOME/Desktop that it will appear in $HOME/Desktop in other programs. Sandboxing or not. I'm happy it works for you though.
  - altfredd 8y ago
    Well, I have used it for years, and never encountered any issues. If you want to share a file between sandboxes you can hardlink it. Or use descriptor-passing. Or… But it feels like you are just looking for theoretical flaws in my personal workflow for the sake of coming up with flaws. Of course, it is silly to sandbox your bread-winning software. I don't sandbox Android Studio. Or ffmpeg. Or VLC. Personally, I believe that nobody has a right to decide, how to sandbox software on other people's computers. I think, that such decision should be left to users of that software. Unfortunately, it looks like Flatpak does not make that easy.
    - mbreese 8y ago
      I'm not very invested in finding flaws in your workflow, but I am happy it works for you. It does sound interesting and I'd honestly like to know more about how you have it setup. I stopped using desktop Linux a long time ago and now use a Mac for my desktop work. I take things a bit further and don't let anything write to my $HOME/Desktop -- it's read-only. I don't recommend that as a default for anyone either! But as far as Flatpak, a few of the "featured" apps are things like Inkscape, Gimp, VLC, or LibreOffice. Not apps that you'd really want to sandbox isolate like you described. (And as you mentioned -- you wouldn't want to do that anyway). Now a few of the others were Spotify and Slack. Things that you could (should?) definitely sandbox. I guess I don't see the point in having applications (that is intended for a general purpose user) that (a) need access to your home directory to read/write files and (b) should only have access to a sandboxed pseudo-home directory. Either sandbox it so it doesn't have $HOME access at all, or don't. I'm not sure I see the benefit to this middle ground. Especially for the use-case of general user desktop applications. For server applications, I could potentially see the benefit (although, containers have probably already filled this scenario). What is the use-case you're thinking of? I appreciate your point of view that no one should be able to decided for you how to sandbox software, but no one is forcing you to use Flatpak packaged programs[1]. Perhaps there should be some way to re-build a Manifest that limits access, or make it so that you can more easily switch granted privileges -- that would probably be a good thing. But someone has to set defaults. If a Flatpak packaged program has too liberal defaults, then maybe that's best treated like a bug and hopefully there is a mechanism to send a patch. [1] yet... but it might be coming. I think the only way you'd see commercial applications like Photoshop for desktop Linux would be wrapped in something like Flatpak. I still think that most open-source applications will still be packaged by the main distro repositories, regardless of how well Flatpak does.
derefr 8y ago
Ways macOS handles the this problem: 1. the File Open dialog is itself the permission prompt. 2. documents consisting of many files are structured into project bundles; you open—and thus grant access to—the entire bundle at once. 3. the GUI is structured to orient activity around documents rather than around applications. You hardly ever launch an app and then open a file in it. Instead, you open the document and the app is its default handler; or you right click the file and Open With the app; or you drop the file onto the app's launcher shortcut; or you drop the file onto the running app window. All of these actions implicitly grant the app permission to open the file, in the same way the File Open dialog does. 4. Apps can persist the token representing this granted permission in a serialized state file, and it will even survive OS reboots. There are some macOS utilities (e.g. DaisyDisk) that need access to your entire disk—but you only need to grant this access once. (DaisyDisk asks, on first startup, for you to open the Finder and drop the icon representing your primary hard disk onto the running app.)
- danieldk 8y ago
  Ways macOS handles the this problem: 1. the File Open dialog is itself the permission prompt. And yet, there are quite some applications that ask you to open the home directory once so that it gets symlinked into their sandbox. It's basically a hack to say 'I need access to your whole home directory'. Of course, it is safer than permitting access by default. Of course, in many cases there are good reasons (backup software, space usage analyzers). But not everything can be mediated through file dialogs.
- int_19h 8y ago
  Same thing for Win10 UWP apps.

blattimwind 8y ago

File picker is privileged and mediates access through monitor. Ditto for drag-and-drop. Problem (largely) solved.

aaaaaaaaaab 8y ago
That’s how macOS sandboxing works too.
TeMPOraL 8y ago
Do you open your files in PyCharm or VSCode through a file picker?
- blattimwind 8y ago
  Drag and drop project folder. Also, yes, I do open project directories using PyCharm's (poor) file picker.
- stephenr 8y ago
  I’d imagine once you open a directory you can open files within it (and child dirs)
- ReverseCold 8y ago
  You open the parent project directory, right? That's how the file access controls work in MacOS. Sandboxed apps can't read files outside their sandbox until the user opens the directory/file in the file picker at least once. (Or something similar, I can't seem to find a source on that...)
  - TeMPOraL 8y ago
    Ah, ok. Makes more sense this way.

deleted 8y ago

[deleted]

gmueckl 8y ago

This highlights a conceptual dilemma with access rights in file systems: if an image manipulation software wants to open .bashrc, this is potentially suspicious. But for a text editor this is probably ok. Likewise, a text editor that reads a binary executable is probably a little bit fishy. But a unzip program might so that for a valid reason (e.g. ZIP archive appended at end of program, a common thing for installers). How can we distinguish between those cases?

briffle 8y ago
This is pretty much the whole point of SELinux (and probably AppArmour)
- geofft 8y ago
  How does SELinux or AppArmor distinguish between those cases? More interestingly, how can it tell that VSCode spontaneously editing .bashrc is bad, but doing so in response to user input is good? (There are capability-based systems that permit distinguishing between these cases, but to my knowledge SELinux and AppArmor don't support this.)
  - Conan_Kudo 8y ago
    SELinux labels users and domain transitions, so it's "technically" possible to do so, but I see that incredibly rarely. I don't think AppArmor has such a facility. It wouldn't make sense, given that AppArmor doesn't know these things like SELinux would.
  - cyphar 8y ago
    SELinux and AppArmor would allow you to specify that your text editor is allowed to edit .bashrc, but some random other program isn't. But I agree with you that this is not really a useful security feature -- you'd want something where a program has to be explicitly granted permission rather than some programs being able to do things that others can't (because then any attacker will just spawn "vi -c 'bad payload'" to get around the restriction).
  - 8y ago

AgentME 8y ago

The sandboxing platform could offer an API so a sandboxed program can spawn a privileged file-open dialog, and then the sandboxed program is only allowed to modify the file/directory that the user picked. With the current situation, calling the programs sandboxed is completely misleading.

audidude 8y ago
You've described the xdg-desktop-portal. Gtk apps just need to switch to GtkFileChooserNative and they get that for free. It does an FD pass of a FUSE fd and the app never gets file-system access. It also has the benefit of using the KDE file-chooser on KDE, Windows file-chooser on Windows, mac, etc...

vanderZwan 8y ago

Could you link to the comment? Would like to read the discussion on Reddit too.

ahreflink 8y ago
https://old.reddit.com/r/linux/comments/9ms96u/flatpak_security_exposed_useless_sandbox/ https://old.reddit.com/r/linux/comments/9ms96u/flatpak_secur...

wongarsu 8y ago

Most use cases of VLC only open files, so giving it universal privileges to open files but a prompt on filesystem writes would be fine. Gimp could have universal read and the right to create new files, but overwriting files it didn't create itself restricted behind a permission prompt. Same for Inkscape and Audacity. If you want to push this further, you could imagine a permission system that can distuingish based on file types. Gimp overwriting a PNG is probably intended, Gimp overwriting a bash script probably not. There's a lot more nuance in existing systems (SELinux) and potential future systems than just "allow everything or nothing".

faho 8y ago
Okay, now do emacs! Depending on build-time options, that can open text files, images, pdfs, archives (zip et al). In fact I'm struggling to think of a single file type that truly won't have a use in emacs. (It might actually make more sense to forbid editting executable files than going via type) ----- >There's a lot more nuance in existing systems (SELinux) and potential future systems than just "allow everything or nothing". The problem isn't that there isn't a lot of "nuance" in these systems, the problem is that there is! Sure, SELinux will work if you have a static system or an SELinux expert under the desk. Creating a system that works and remains understandable is much harder.
int_19h 8y ago
> but overwriting files it didn't create itself restricted behind a permission prompt It's more nuanced than that. A user might not even have a .bashrc, but you still don't want to allow any random app to create one. In general, it feels like the security model for the FS has to distinguish things that can be executed, and things that cannot. Which it already does on Unix with +x, but then you've got all the scripting languages that cheerfully ignore that, and all the apps that use executable configs etc. If you can fix all those such that +x is required for any source of executable code on the system, then you can just prohibit apps from creating +x files. But the cost of doing that in the existing ecosystem is enormous.

altfredd 8y ago

There is no reason to make it complicated. Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop. I have been using a directory-per-program sandboxing setup for several years (and still do). It is very convenient, and does not require any additional effort to adapt. In fact, I now have less clutter in my actual $HOME than ever before. Programmers like to come up with clever ways to solve nonexisting problems. I say — give user a way to bootstrap a sandboxed environment into a directory of their choice (no, using auto-generated directory names is NOT allowed!), and the "problem" would no longer exist.

mbreese 8y ago
I'm sorry, but that solution isn't workable to many (likely a majority of) users. Most will expect that when you open two programs that need to work on the same file, that if you save the file to your $HOME/Desktop that it will appear in $HOME/Desktop in other programs. Sandboxing or not. I'm happy it works for you though.
- altfredd 8y ago
  Well, I have used it for years, and never encountered any issues. If you want to share a file between sandboxes you can hardlink it. Or use descriptor-passing. Or… But it feels like you are just looking for theoretical flaws in my personal workflow for the sake of coming up with flaws. Of course, it is silly to sandbox your bread-winning software. I don't sandbox Android Studio. Or ffmpeg. Or VLC. Personally, I believe that nobody has a right to decide, how to sandbox software on other people's computers. I think, that such decision should be left to users of that software. Unfortunately, it looks like Flatpak does not make that easy.
  - mbreese 8y ago
    I'm not very invested in finding flaws in your workflow, but I am happy it works for you. It does sound interesting and I'd honestly like to know more about how you have it setup. I stopped using desktop Linux a long time ago and now use a Mac for my desktop work. I take things a bit further and don't let anything write to my $HOME/Desktop -- it's read-only. I don't recommend that as a default for anyone either! But as far as Flatpak, a few of the "featured" apps are things like Inkscape, Gimp, VLC, or LibreOffice. Not apps that you'd really want to sandbox isolate like you described. (And as you mentioned -- you wouldn't want to do that anyway). Now a few of the others were Spotify and Slack. Things that you could (should?) definitely sandbox. I guess I don't see the point in having applications (that is intended for a general purpose user) that (a) need access to your home directory to read/write files and (b) should only have access to a sandboxed pseudo-home directory. Either sandbox it so it doesn't have $HOME access at all, or don't. I'm not sure I see the benefit to this middle ground. Especially for the use-case of general user desktop applications. For server applications, I could potentially see the benefit (although, containers have probably already filled this scenario). What is the use-case you're thinking of? I appreciate your point of view that no one should be able to decided for you how to sandbox software, but no one is forcing you to use Flatpak packaged programs[1]. Perhaps there should be some way to re-build a Manifest that limits access, or make it so that you can more easily switch granted privileges -- that would probably be a good thing. But someone has to set defaults. If a Flatpak packaged program has too liberal defaults, then maybe that's best treated like a bug and hopefully there is a mechanism to send a patch. [1] yet... but it might be coming. I think the only way you'd see commercial applications like Photoshop for desktop Linux would be wrapped in something like Flatpak. I still think that most open-source applications will still be packaged by the main distro repositories, regardless of how well Flatpak does.

derefr 8y ago

Ways macOS handles the this problem: 1. the File Open dialog is itself the permission prompt. 2. documents consisting of many files are structured into project bundles; you open—and thus grant access to—the entire bundle at once. 3. the GUI is structured to orient activity around documents rather than around applications. You hardly ever launch an app and then open a file in it. Instead, you open the document and the app is its default handler; or you right click the file and Open With the app; or you drop the file onto the app's launcher shortcut; or you drop the file onto the running app window. All of these actions implicitly grant the app permission to open the file, in the same way the File Open dialog does. 4. Apps can persist the token representing this granted permission in a serialized state file, and it will even survive OS reboots. There are some macOS utilities (e.g. DaisyDisk) that need access to your entire disk—but you only need to grant this access once. (DaisyDisk asks, on first startup, for you to open the Finder and drop the icon representing your primary hard disk onto the running app.)

danieldk 8y ago
Ways macOS handles the this problem: 1. the File Open dialog is itself the permission prompt. And yet, there are quite some applications that ask you to open the home directory once so that it gets symlinked into their sandbox. It's basically a hack to say 'I need access to your whole home directory'. Of course, it is safer than permitting access by default. Of course, in many cases there are good reasons (backup software, space usage analyzers). But not everything can be mediated through file dialogs.
int_19h 8y ago
Same thing for Win10 UWP apps.