I did a bit more research on Flatpak since this email and it seems that
Flatpak covers all of the use cases I mentioned.
Flatpak is not a dependency system so application bundles cannot depend
on each other. Each application is self-contained, aside from the
specific "runtime" on which it relies.
So in a world where Flatpak has broad consensus, it seems like the
distribution's package manager becomes more relevant for system building
and development. Not so much for installing applications.
On 2022-05-02 13:02, Michael Stapelberg wrote:
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.
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
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 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
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
