Hypothetical: A vulnerability in Chrome could allow a remote attacker the ability to read/write arbitrary files on your filesystem. /tmp/.X11-unix/X0 for example. This could let them cause all sorts of havoc on your X11 display including controlling/compromising other running programs (and capturing your keystrokes).
If Chrome were sandboxed as described in the article such an attack would not be possible without first breaking out of the sandbox.
Unless you personally built software from trusted source with a trusted toolchain, or reverse-engineered and inspected the binary package you are installing, you have no more confidence that your installed binary package is not malicious than any proprietary binary blob. Even presuming the maintainer and packager is not malicious (and why would you trust a random open source maintainer more than a random proprietary maintainer?), there have been cases in the past where repositories have compromised and with malicious packages inserted. These are just the ones we know about. Signatures help but don't solve anything; especially with distributed projects, keys can be compromised in any number of ways. And don't help with malicious actors.
That said, I don't see sandboxing Linux apps as particularly revolutionary. Users, ACLs, and chroots have been around for ages. While not especially sugary, they are pretty effective. For full-on app sandboxing, Android is Linux, and they've been doing this since 2008. The average Linux desktop user has legitimate reasons they don't want to sandbox any given desktop app to this extent. On the server side, "sandboxing" in the form of "separation of privileges" has been standard best practice in the UNIX realm as long as Richard Stallman's beard. This is just not particularly interesting. More interesting to me is what has been done for sandboxing in the browser, most especially Chrome.
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.