[distri] Sandboxing for applications in distri?
- From: Michael Stapelberg <michael+distri@xxxxxxxxxxxxx>
- To: Hydro Flask <hydroflask@xxxxxxxxxxx>
- Date: Mon, 2 May 2022 09:48:27 +0200
[replying on the mailing list as discussed]
On Sun, 1 May 2022 at 00:03, Hydro Flask <hydroflask@xxxxxxxxxxx> wrote:
Thanks for your reply.
In terms of sandboxing, I mean something a lot less heavyweight than Qubes
OS. Something that enables mostly trust-less installation of applications
like on iOS.
In practical terms on a Linux desktop I think that that restricting
filesystem access would cover majority of use cases:
1) No access to personal information by default, i.e. the home directory
would not be accessible without giving specific permission to files
2) No writable access to anywhere in the file hierarchy except a
designated app folder (for storing caches and app-specific data).
Filesystem sandboxing makes a lot of sense to me, and seems to be the only
kind of sandboxing that I can imagine can work for many applications, while
also providing lots of value to users.
In https://github.com/gokrazy/rsync, I use mount namespaces to accomplish a
very similar setup: the rsync process literally only has access to the
directories that were configured to be served world-readable.
Downsides I see are that the use of mount namespaces requires root
permissions, and that inherently, it’s not possible to grant more
permissions later. For example, you can’t have a photo editing app that
requests permission for a single photo.
Perhaps others on this list know if there already is some prior art in this
AFAICT, this would have to happen at some other layer than what distri
Perhaps with some additional kernel support?
This would also require restricting run-time access to the data of other
processes. For example, locking down access to /proc, process_vm_readv(),
ptrace(), framebuffer and input data via X11. At least Wayland seems to
implement the last part.
Here I’m a lot less certain about whether it’s worthwhile to do these
Filesystem sandboxing itself protects against poorly written software and
The protections you’re suggesting here protect against purposefully
But, purposefully malicious software can usually find a way to do harm.
See the recent dirty pipe or nimbuspwn vulnerabilities.
Maybe this is an overly negative outlook from my end, but the value
proposition of losing ptrace (for example) just so that malware has a
slightly harder time (but may well succeed regardless) just doesn’t seem
too compelling to me.
Other related posts: