edohyiez

Ah, That explains it. Thanks! And to semenko too.

I find it a bit weird that it can MITM https://www.google.com/ on Chrome. I thought Chrome did CA-pinning for Google-domains.

GTK indirectly depends on libpng, so that probably wasn't the best example ;)

The thing is that Linux distributions traditionally don't make any difference between the OS and apps. Everything is split into relatively small packages. Like everything this model has some advantages (e.g. security updates) but also some disadvantages (it's harder to distribute/install software outside the distribution).

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?

This isn't about isolating users from each other, but isolating different applications running as the same user from each other. X11 (and Unix itself) was not designed to do this.

Also, kdbus has nothing to do with graphics.

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.

And you're creating a strawman. rodgerd didn't say that the only two options were SysVinit and systemd, but that the loudest critics of systemd wanted to keep SysVinit. Whether that's true or not is another point (and not objectively decidable since "loudest" is pretty subjective), but it's obviously not the false dichotomy you're accusing him of.

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

The main argument against this kind of bundling (apart from higher disk usage) is about security updates of libraries. E.g. if many applications ship their own copy of OpenSSL and another vulnerability is discovered, you have to update every application individually. And it is unlikely that all developers/vendors will provide such updates fast enough.

But if all applications use the same OpenSSL that is managed by dpkg+apt (or something similar), a single update will fix all applications.

Personally, I don't think that this problem can be solved without losing the advantages of bundling (robustness, reproducability, binary portability to other distributions).

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

Then the media player can read every DVD you put into your drive as long as its running. So you always have to close the media player before inserting a DVD containing private files. That probably isn't that important for DVDs, but for other devices (e.g. microphone, webcam) it certainly is.

No. Why would it? The user can still grant full access to the machine to applications they trust (like they do now). In fact, the traditional Unix security model (root vs. regular users) was about "not trusting the user" and securing the machine from the user. This "new" kind of sandbox is about the user being able to apply different levels of trust to different applications.

It's not about "not trusting the user", but about the user not having to trust the author of the application.