I just learnt about the Portal API, which does exactly what I had in mind:
https://who-t.blogspot.com/2021/08/flatpak-portals-how-do-they-work.html
So, it seems like the answer is to use Flatpak with applications that use
the Portal API? :)
On Mon, 2 May 2022 at 09:48, Michael Stapelberg <
michael+distri@xxxxxxxxxxxxx> wrote:
[replying on the mailing list as discussed]
Hey
On Sun, 1 May 2022 at 00:03, Hydro Flask <hydroflask@xxxxxxxxxxx> wrote:
Thanks for your reply.Filesystem sandboxing makes a lot of sense to me, and seems to be the only
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).
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 space?
AFAICT, this would have to happen at some other layer than what distri
currently provides.
Perhaps with some additional kernel support?
This would also require restricting run-time access to the data of otherHere I’m a lot less certain about whether it’s worthwhile to do these
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.
lock-downs.
Filesystem sandboxing itself protects against poorly written software and
misconfigurations.
The protections you’re suggesting here protect against purposefully
malicious software.
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.
Best regards
Michael
