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.
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.
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.
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.
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.
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).
> 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.
That's SELinux, if configured well. Files are labeled according to their function and access to these files is whitelisted according to the security label of a process. For example, no security labelled process can access my private ssh keys, that's guaranteed.
It's just a shame that SELinux has such a documentation and UX issue, so almost no one uses it and almost no one uses it well - except for package maintainers and some application developers.
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.
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.
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.
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.
