[cplease]

It depends on what you mean by "sandboxing" and "app." But basically, with a browser or mobile app, there's a limited number of functions that you may want to permit an app to access, and it's okay to isolate the rest of the app to its own little world. With desktop apps, you generally want to be able to use apply them broadly to all your user data, or you will quickly be frustrated with them.

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.

[edohyiez]

I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect.

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

[cplease]

> I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect.

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.

[edohyiez]

Yes, I want applications to be able to open files and to work together, but only if that's needed to achive what I want them to do. LibreOffice should be able to open (and read from and write to) any .odt-file that I want to edit. But since to do that it doesn't need to have access to my browsing history, I don't want it to have access to that. Is it weird that I want that?

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

[detaro]

A file chooser outside the application is safer if the sandbox enforces that only selected files are opened. Of course I want the app to be able to read files I told it to open, but it shouldn't be able to access files I haven't selected.

[pmontra]

How about the sub files with the same name of the video file you selected? Some players open them automatically and it's very convenient. I'm sure there are other cases like that.

[detaro]

Just because it can't cover every single case and application doesn't mean it isn't worth using it for those where it fits. It's an interesting question how far one would want to go to support these special cases, because doing so adds complexity to both code and the things the user has to understand, but the nice thing with an open system is: we don't have to use it for applications that don't fit the model very well or can allow exceptions where needed.

[cplease]

You don't need a different file chooser widget for that. You can use AppArmor or other MAC systems.

[edohyiez]

Can you really? With the external file chooser, the app has no access to user files before a file is picked, then has access to only this one particular file, and after it is closed returns to no access again.

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?