4 ms·

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

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.
tetha 6y ago
> 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.

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.

tetha 6y ago

> 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.