5 ms·

You want the meaning of sandboxed in flatpak changed, and for it not include access to the home dir? That seems fair. But with the current UI, I think most peop

by noja 6y ago

You want the meaning of sandboxed in flatpak changed, and for it not include access to the home dir? That seems fair. But with the current UI, I think most people expect that a video player can open video files in their home directory.

Semaphor 6y ago
I never used a system with flatpak, but when I read sandboxed I expect the maximum permission to be read-only access to my home directory or something like android where it asks for additional permissions.
- gommm 6y ago
  Read only is already giving the keys to the kingdom if internet connections are not limited. Any sandboxing that doesn't protect against exfiltrating private documents is not sandboxing at all. It's fine if it's a trade off between usability and security but then they shouldn't call it sandboxing or make it very clear that that's the trade off.
  - silon42 6y ago
    +1... need outgoing connections whitelisting, blocking all by default.
jmillikin 6y ago
For effective sandboxing you have to integrate something like capability passing and delegated access. For example, opening a file with drag-and-drop should allow access to that file, and the File > Open menu should do the sandbox equivalent of a hypercall to open a privileged file browser widget.
- tgragnato 6y ago
  Or, make people aware they are passing files between different sandboxes. ..à la Qubes.. https://www.qubes-os.org/doc/copying-files/ https://www.qubes-os.org/doc/copying-files/
- CodesInChaos 6y ago
  I agree that this kind of capability is essential for usable sandboxing on desktop systems. Though the trusted filepicker is tricky to do when one logical document consists of multiple files. For example separate subtitle files next to a video file are common.
  - sammorrowdrums 6y ago
    I think this is also true for a lot of ebook meta files. Some have separate thumbs and things. Certainly one could select all the files and drop them in. But that's asking a lot of the opening program, and isn't usually how they're set up.
  - zaarn 6y ago
    This could be reasonably expressed. Flatpak can sort of do this via portals, you have a filepicker that can see the host system and the picked file is transparently mounted into the app container. For multiple files per document, the solution would be either multi-file select (bad) or allowing apps to specify very simple rules for additional files, ie "removing extension, also mount all files starting with that name". The filepicker could integrate that and either show all those files as a single document or select all files for a document visible, so the user is informed.
  - imtringued 6y ago
    The idea behind sandboxing is that you explicitly grant access to files and directories to specific apps. Your ~/Videos folder can be made accessible to mpv or whatever video player you're using.
detaro 6y ago
Isn't that what flatpak portals were supposed to solve? I think then it's fair to say that an app that doesn't make full use of the advertised sandboxing features of flatpak shouldn't get an unqualified checkmark on that.
xioxox 6y ago
It could at least prevent access to dot files or places where dangerous things could be dropped (e.g. ${HOME}/bin).
sammorrowdrums 6y ago
Yeah - I mean certainly home folder with restrictions would be good. Things link dotfiles in home and ~/.ssh should certainly not be accessible or editable by a sandboxed application without knowledge. I think the Downloads, Documents and Movies folders people tend to have etc. those major sub-folders would be enough for normal use. Also, perhaps file type limits could be imposed that mean at that files are only accessible to apps that can open them. Of course, I'd want my text editor to be able to open files across root file system, if I open it as root - so I can see how quickly a person can want sandboxing, and then also want none - but the less apps with privileged access, the better. Also I think some people had hopes it would be closer to IOS level sandboxing, which is heavily restricted on file access, and frankly can be annoying because of it, but does have the security benefit at least. Also, the security update gripe is significant. The isolation of packages only matters if it works. Like at least if I run stuff myself inside container, I can choose to update the underlying OS and force certain packages etc. at the same time as sandboxing, and mount only certain folders if I actually need them. I think it's hard to make it both simple for users and powerful enough provide the levels of granular access I'd expect for context specific sandboxing. I would want a principle of least required privilege, with some ability to escalate it (like Android asks me all the time if I want to allow software to do stuff at point of the privilege being required). I had high hopes for Flatpack, Elementary OS went all in on it for a better way to deliver their curated apps. https://blog.elementary.io/elementary-appcenter-flatpak/ https://blog.elementary.io/elementary-appcenter-flatpak/ I guess though, they curate and approve the apps, so perhaps they are able to make certain assurances that are not universal to Flatpak availability.
- zaarn 6y ago
  The text-editor case is somewhat solved by portals and could be expanded upon. The texteditor gets no FS access. Instead the call the portal to request the user to pick a folder (for projects) or file with a specific ending (the compatible file formats or if folders can be picked can be defined statically for most apps). If the app was started with root privileges, it gets no root privs but the portal transparently translates it's IO calls to the actual file. But only that file. So even if the text editor had a CVE, it couldn't overwrite arbitrary files, still needs permission from the user by showing them a file picker dialog. And you could still ban certain directories, so even if you started as root, the text editor cannot access /etc/sudoers and /etc/passwd, for example.

by noja 6y ago

Semaphor 6y ago

I never used a system with flatpak, but when I read sandboxed I expect the maximum permission to be read-only access to my home directory or something like android where it asks for additional permissions.

gommm 6y ago
Read only is already giving the keys to the kingdom if internet connections are not limited. Any sandboxing that doesn't protect against exfiltrating private documents is not sandboxing at all. It's fine if it's a trade off between usability and security but then they shouldn't call it sandboxing or make it very clear that that's the trade off.
- silon42 6y ago
  +1... need outgoing connections whitelisting, blocking all by default.

jmillikin 6y ago

For effective sandboxing you have to integrate something like capability passing and delegated access. For example, opening a file with drag-and-drop should allow access to that file, and the File > Open menu should do the sandbox equivalent of a hypercall to open a privileged file browser widget.

tgragnato 6y ago
Or, make people aware they are passing files between different sandboxes. ..à la Qubes.. https://www.qubes-os.org/doc/copying-files/ https://www.qubes-os.org/doc/copying-files/
CodesInChaos 6y ago
I agree that this kind of capability is essential for usable sandboxing on desktop systems. Though the trusted filepicker is tricky to do when one logical document consists of multiple files. For example separate subtitle files next to a video file are common.
- sammorrowdrums 6y ago
  I think this is also true for a lot of ebook meta files. Some have separate thumbs and things. Certainly one could select all the files and drop them in. But that's asking a lot of the opening program, and isn't usually how they're set up.
- zaarn 6y ago
  This could be reasonably expressed. Flatpak can sort of do this via portals, you have a filepicker that can see the host system and the picked file is transparently mounted into the app container. For multiple files per document, the solution would be either multi-file select (bad) or allowing apps to specify very simple rules for additional files, ie "removing extension, also mount all files starting with that name". The filepicker could integrate that and either show all those files as a single document or select all files for a document visible, so the user is informed.
- imtringued 6y ago
  The idea behind sandboxing is that you explicitly grant access to files and directories to specific apps. Your ~/Videos folder can be made accessible to mpv or whatever video player you're using.

detaro 6y ago

Isn't that what flatpak portals were supposed to solve? I think then it's fair to say that an app that doesn't make full use of the advertised sandboxing features of flatpak shouldn't get an unqualified checkmark on that.

xioxox 6y ago

It could at least prevent access to dot files or places where dangerous things could be dropped (e.g. ${HOME}/bin).

sammorrowdrums 6y ago

Yeah - I mean certainly home folder with restrictions would be good. Things link dotfiles in home and ~/.ssh should certainly not be accessible or editable by a sandboxed application without knowledge. I think the Downloads, Documents and Movies folders people tend to have etc. those major sub-folders would be enough for normal use. Also, perhaps file type limits could be imposed that mean at that files are only accessible to apps that can open them. Of course, I'd want my text editor to be able to open files across root file system, if I open it as root - so I can see how quickly a person can want sandboxing, and then also want none - but the less apps with privileged access, the better. Also I think some people had hopes it would be closer to IOS level sandboxing, which is heavily restricted on file access, and frankly can be annoying because of it, but does have the security benefit at least. Also, the security update gripe is significant. The isolation of packages only matters if it works. Like at least if I run stuff myself inside container, I can choose to update the underlying OS and force certain packages etc. at the same time as sandboxing, and mount only certain folders if I actually need them. I think it's hard to make it both simple for users and powerful enough provide the levels of granular access I'd expect for context specific sandboxing. I would want a principle of least required privilege, with some ability to escalate it (like Android asks me all the time if I want to allow software to do stuff at point of the privilege being required). I had high hopes for Flatpack, Elementary OS went all in on it for a better way to deliver their curated apps. https://blog.elementary.io/elementary-appcenter-flatpak/ https://blog.elementary.io/elementary-appcenter-flatpak/ I guess though, they curate and approve the apps, so perhaps they are able to make certain assurances that are not universal to Flatpak availability.

zaarn 6y ago
The text-editor case is somewhat solved by portals and could be expanded upon. The texteditor gets no FS access. Instead the call the portal to request the user to pick a folder (for projects) or file with a specific ending (the compatible file formats or if folders can be picked can be defined statically for most apps). If the app was started with root privileges, it gets no root privs but the portal transparently translates it's IO calls to the actual file. But only that file. So even if the text editor had a CVE, it couldn't overwrite arbitrary files, still needs permission from the user by showing them a file picker dialog. And you could still ban certain directories, so even if you started as root, the text editor cannot access /etc/sudoers and /etc/passwd, for example.