> The average Linux desktop user has legitimate reasons they don't want to sandbox any given desktop app to this extent.
Could you expand on that?
Could you expand on that?
Deeper-level sandboxing of splitting the app up into bipartite high and low-security/complexity components, as with the Chrome browser, requires a lot of engineering for the particular application and can't simply be dropped in place on a given off-the-shelf Linux app.
Coarser-level application-specific permissions in the form of AppArmor profiles, installing daemons as their own users with chroots etc, is already available and deployed. The technology to go further with it is already there.
Of course it's important that the sandbox doesn't frustrate you or lead you to blindly click "Allow" all the time. It would obviously be bad if you get a dialog asking "Application X wants to open file Y. Allow/Deny" whenever an app attemts to access a file. But I don't think that that's the only way to design a sandbox.
For the simple case of opening a file with an app, it could be enough if the app calls a trusted file-chooser outside the sandbox which then returns an opened fd to the file the user chose. Then the user wouldn't even notice that there was a sandbox. Of course that's not enough for all usecases (see some other comments from jbk about VLC).
You do want LibreOffice, Gimp, VLC, and your webbrowser to be able to save and open their respective media files in your home folder, right? And you want might want them to be able to actually work together, right? Such as opening a file you downloaded in the browser. Whether the file chooser is inside your application or outside your application doesn't make it any safer, it's the fact that the application has the ability to open and read/write the files.
What you seem disturbed by is that one application can access configuration and state data belonging to another application. Because they are just files, belonging to the same user. Well, I suppose if such a policy made you feel better, you could always change the AppArmor profiles to only allow an application to modify its own dotfiles, dotdirectory, e.g., fooapp can't touch ~/.* except ~/.fooapp. That's not a terrible idea, although if you are so distrustful of it to begin with and still want to run it you should probably sandbox it in its own filesystem altogether. And this will break some interoperability.
How would you do this with a generic MAC system without using additional software that dynamically changes the MAC policy and/or relabels files and without bothering the user?
> Whether the file chooser is inside your application or outside your application doesn't make it any safer, it's the fact that the application has the ability to open and read/write the files.
Yes, it does. If the file chooser is inside the application, it needs to be able to open the chosen file, i.e. an arbitrary path, at any time. If the file chooser is outside the sandbox, the application only gets the open fd and can't open files itself (open(2) would simply fail). That is a huge difference!
> What you seem disturbed by is that one application can access configuration and state data belonging to another application.
Yes, I am disturbed by that and I am certainly not alone. There simply is no reason why it should be that way, apart from backwards-compatibility. Why should I have to trust the hundreds of millions of lines of code in all the applications on my machine, if such a huge amount of trust is not necessary to achive the desired outcome?
And sure, application sandboxing can already be achived with AppArmor or SELinux (or a multitude of other systems), but it requires manual work (afaik no major distribution comes with this out of the box) and (as you correctly write) it breaks interoperability. The goal of this "Gnome app sandbox" isn't to be the first application sandbox, but to provide the possibility to enable this by default for certain applications and to keep interoperability. That last part is mostly a research project, so I don't expect this to be finished any time soon.