"We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate"
I think that's fair, or at least it has traditionally been a fair assumption for most users.
The issue here is that your hardware vendor has compromised your machine, so that is no longer a fair assumption.
Well continue the process. Suppose Chrome did flag such things. That'd break a lot of "legitimate" use cases, and someone would implement a workaround. For instance, they could just patch the Chrome binaries to disable the warnings or change the pinning logic. Insert their own certs into the pin list. Without something like Intel SGX, you or Google can't totally win.
Of course, Chrome could give some indication like a lock+eyeball or something, and hope the interception vendors are too lazy to bother modifying the code. They could also only disable warnings if the machine is connected to a domain or other management system.
There's another issue with ignoring cert pining with user-added root certificates: if you add a root certificate that's missing on your client machine (for instance CAcert or your national CA like ICP-Brasil), the CA you added can bypass pining, even though it shouldn't be able to.
The company I work for has a strict policy of no direct outbound connections from the corporate network. This is to prevent (or just make harder) for compromised machines from "phoning home".
This has the unfortunate side effect that all internet traffic must go through a proxy, they have to MiTM SSL traffic.
I just use my smartphone's data for any personal internet browsing.
Well you don't have to MITM SSL in order to proxy it, it can be done in other ways. They probably choose to do so in order to see the details of the request.
Correct, the firewall intercepts all traffic looking for potential compromises and blocks it. Given all these corporations getting hacked, such measures seem necessary.
Conclusion does not follow from premise. Once an attacker's code is running on machines that have access to sensitive data, you've already lost - there's no way to prevent it smuggling the data out in legitimate-looking requests. The right way is to stop the bad stuff getting in in the first place.
Not all attacks are perfect. It's true that an attacker can potentially do anything once in control of machines with sensitive data, but it doesn't mean that all hope is lost. If an intrusion detection system catches some x% of potential threats, it can easily be worth it.
The goal is to slow them down, put as many barriers as possible allowing higher chances of detecting them. Intercepting and blocking known "phone home" messages is one way to slow them down.
btw, I took a look at google's cert in my corp network and we are getting the real one from google, so my corp is not MiTM SSL traffic from some sites right now.
What does your company do if you have to access a TLS site which uses client certificates for authentication? AFAIK, client certificates don't work when there's a MITM on the TLS traffic, since the MITM proxy doesn't have a way to produce a client certificate that will be accepted by the server.
It's called defence in depth. If you can prevent 99% of malware infections and can prevent 75% of malware from phoning home, you have a 99.75% confidence (1 in 400) of not having a data leak due to a compromised machine. That's 4 times better than only preventing infections.
The line between what computing should be done on what device is blurry in both directions -- it's not just "people do personal computing on corporate devices". It'd be a bit strange to hear a boss tell me to never browse Amazon or Hacker News during lunch.
I think it's wise to assume corporate-owned devices are just that: 0wned by corporations.
I use my work laptop all the time for a variety of things, but I do so under the assumption that the company may be snooping on me. (No idea if they are or not.)
Exactly. It's a work machine, used for doing work. I don't do private/personal/secure things on it, as it's not my personal computer. Browsing HN or w/e isn't really a private activity, so I don't mind it being snooped.
I guess I should look into the Chromium source to disable this MITM "feature"... I'm really too busy so if anyone else does this I'd much appreciate a patch.
Maybe it triggers the logic that allows (supposedly) user-added certs to override those pins? (Google was pressured into adding such logic by corporate users, whose IT departments want to -- supposedly openly -- MITM employees' connections.)
Edit: I think that's the case. AGL's original announcement of pinning said:
"There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certificates. These certificates are signed by a root certificate that has to be manually installed on the client. Corporate MITM proxies may do this, several anti-virus/parental control products do this and debugging tools like Fiddler can also do this. Since we cannot break in these situations, user installed root CAs are given the authority to override pins. We don't believe that there will be any incompatibility issues."
If Chrome thinks that this was a "user installed root CA", it would have been allowed to override the pin. (Disclaimer: I haven't checked that this is right, I'm just using my recollection of how this could work according to AGL's account.)
It points to an interesting problem that, while browser vendors officially think that users ought to be notified when someone is using an intercepting proxy -- that it shouldn't be invisible to them -- when users aren't installing their own OS or configuring their own browser, it could be completely invisible in practice.
So the IT department-installed or OEM-installed cert is treated as "user-installed" by the pinning logic, and the user never actually gets warned.
As someone who respects your work, I would suggest that perhaps the more interesting problem is EFF's structural inability to do anything but apologize for Google policies and practices that clearly and obviously harm user freedom and privacy.
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.
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.
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).
Right, but there's a difference between things that the OS is expected to provide (OpenSSL, GTK, etc) which the app should not bundle, and things like libpng which the app basically should bundle.
e.g. Windows supplies KERNEL/USER/GDI as builtins, but doesn't supply libpng.
Pretty much the whole point of an OS is to provide a guaranteed stable base. Anything that isn't guaranteed or stable should be bundled with the app.
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).
I would argue that you shouldn't bundle any libraries at all. As a package maintainer, I get real annoyed at projects that bundle things like libpng and don't provide an easy way to use an already built version.
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.
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).
> 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.
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.
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.
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.
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.
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?
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.
I can see this being useful for running proprietary and non free software. However, we should strive for all software to be free software instead. Because if I download free software, I have the community of developers to vouch for it. If I download proprietary software, I can't really trust it.
My answer to that is "heartbleed". It is irrelevant if you trust the developers - sometimes those developers will make mistakes. Sometimes those mistakes will be serious.
The less privileges your applications run with, the less likely it will be that exploits will affect you.
