Just goes to show that not all sandboxes are created equal (though I don't think I've ever even used a properly sandboxed Windows or Linux app, so those OSes don't get any points anyway). For example, reading other tabs or processes out of the web browser sandbox isn't possible short of exploits like Spectre and Meltdown, and even seeing something like the history of visited links requires cleverly tricking the user (and coarse guesswork) e.g. https://tinsnail.neocities.org/ and http://lcamtuf.coredump.cx/yahh/ . I imagine the behavior in the OP is impossible on both Android and iOS too?

There was a pre-Spectre proof of concept of a program telling what tabs you have open in your web browser: https://github.com/defuse/flush-reload-attacks

This was a program rather than another webpage, and I haven't bothered to read how it worked beyond the general idea of exploiting a cache side-channel. I expect the bit-rate is low compared to Spectre/Meltdown. But it made me leery of confidentiality in current systems.

I think you have the idea of sandbox (or at least the idea of sandbox in the context of a web browser) backwards: it means an application (webpage) running inside the sandbox cannot access resources not granted. This side channel access does not run inside a sandbox at all.

If you don't consider an OS process a sandbox at all, why are even talking about security here?

That’s not the point of GP though? The whole premise of virtualization is that an OS process is not a perfect sandbox. There’s a hierarchy of sandboxes. Protecting other processes from accessing something inside the sandbox is not the job of a browser sandbox. This actually just goes to show the GP’s point: not all sandboxes are created equal.

I was not arguing against kibwen, I was sharing some more points. People have implicitly expected OS processes to be better isolated from each other than they are. (I think there's a related problem that people tend not to think about which of the properties of integrity, confidentiality, and availability they rely on.)

You might not be able to escape the browser's sandbox, but you can certainly escape your tab's sandbox and spy on other tabs using timing attacks: https://www.usenix.org/system/files/conference/usenixsecurit...

If you've used Chrome, you've used a properly sandboxed app on both. I believe Firefox also now uses the Chrome sandbox on Windows. And this is definitely not routine to accomplish on iOS or Android.

I think what's concerning is that advertising that an app is in a sandbox suggests to those out of the know that they can use it safely. They expect that the integrity and privacy of their information will be preserved. That expectation does not exist with ordinary win32 or Linux programs.

Are windows store apps sandboxed? If so, is it trivially easy to do this with those? Or is it just win32?

True UWP apps are sandboxed and probably can't do this. They have access to a limited version of the Win32 API, I believe.

X11 is way worse; any app can subscribe to events of any other app, making keyloggers and other nastyware a piece of cake.

This is a feature, not a bug, it is how you can compose an environment out of reusable components that are meant to do one thing by themselves. Tools like xbindkeys and xdotool work using this feature and the composability of X is how you can use the file manager from KDE with standalone window manager like i3 and a separate compositor (or no compositor). X is highly composable, even if many applications ignore that feature. If you know what you are doing you get a lot of power and flexibility with X, way more than any other window system (including Windows).

Proper/secure composability is designed not by exposing all internals, but by explicit APIs. For example, UNIX file descriptions and using them as stdin/stdout/stderr is a properly exposed API for reusable components, while the ability to plug into any function in the binary would not be.

X11, i.e. some of its implementations, don't expose all internals, and clients don't just plug into any function in the binary. The X11 protocol and some of its extensions clearly define how clients can communicate with each other or the server.

Wayland on the other hand does not. How and if clients can communicate with each other is considered out of the scope of the Wayland protocol, except a few exceptions (e.g. copy/paste) so it's up to the Wayland compositor. That's why there are already multiple different "APIs" to do screenshots on Wayland compositors, some more powerful some less, and not a single one is implemented by all major compositors - basically fragmentation hell. That's also why stuff like color pickers still don't work without tedious hacks (e.g. misusing some of the screenshot APIs).

It doesn't expose its internals, the equivalent to UNIX file descriptors in X is the XID (Window, Pixmap, etc). Much like you can give any process any file descriptor to work with, you can also give any process any XID to work with. And like you can combine the text output of processes by redirecting their stdio, you can combine the graphical output by combining their elements (it isn't exactly equivalent of course, partly due to increased complexity inherent in GUI applications but also due to little standardization and tools, but still several of elements in an X desktop - outside GNOME and KDE that implement their own functionality which ignore X - work like that).

> any app can subscribe to events of any other app

Yes, that's a feature I have used many times in the past. If you want to sandbox an app, run it through a nested X server.

Indeed.

And for Windows, more than once I wrote stuff that captures or injects keystrokes globally. Being able to do this is a feature that lets you solve problems by making things more interoperable.

AFAIK you can't get any hardware acceleration that way.

Depends on the X server, i think Xnest uses just a dumb framebuffer but i think Xephyr can use acceleration just fine.

Wow, i have a lot to learn.... Do you know if these sort of things are still possible on wayland ? What about a Flatpak app on Wayland, does that help ? Because I think I've read somewhere that Flatpak apps on X11 was this way, implying that with Wayland it wasn't. I wish i had more time to dive into this sort of stuff...

Flatpak does aggressively isolate apps from the OS though: http://docs.flatpak.org/en/latest/working-with-the-sandbox.h...

Wayland indeed closes a lot of these huge holes. It's one of the core reasons for its introduction.

Flatpak has no X11 sandbox. Others, like Firejail, have attempted to create X11 sandboxes, but they've had holes (last I tested they had the X RECORD extension enabled, which has no use except being a keylogger), or broke valid applications / accessibility tools.

No, Wayland doesn't close any of those huge holes. That's like saying: We removed all the windows to your house, you should now be safe from people spying on you or stealing your stuff.

Wayland doesn't grant Wayland clients permission to those resources, but without further sandboxing and using technologies like Linux namespaces, AppArmor, SELinux, ... that's completely useless in itself. Wayland only makes it harder/impossible for trustworthy applications to do their job, while malicious applications just take one of the many other routes to get what they want.

> Wayland doesn't grant Wayland clients permission to those resources, but without further sandboxing and using technologies like Linux namespaces, AppArmor, SELinux, ... that's completely useless in itself. Wayland only makes it harder/impossible for trustworthy applications to do their job, while malicious applications just take one of the many other routes to get what they want.

What you described is exactly the paper of Flatpak, I think it even used SELinux for it. AFAIK, Flatpak with Wayland is a good way to sandbox apps on Linux.

A good way to sandbox applications is where you get a secure system without much effort but you still can grant applications certain privileges, because as a matter of fact some applications just need access to sensitive data to do their work. With Wayland that's basically impossible, since there's no standardized way to grant your hotkey manager access to the global input, or your color picker permission to read the color of an arbitrary pixel on the screen, ... It's security by not doing anything.

With X11 on the other hand I can sandbox X11 clients I don't trust, thereby limiting them in what they can do, but other clients I do trust have the ability to do all sorts of great things so I can do my work efficiently. While not perfect, not even close, it's certainly better than not being allowed to do anything.

Windows 10 closed this hole.

How so? In java I can access all screens without requesting a permission.

Windows NT (way back to its original 3.1 release) always had the idea of multiple independent desktops where applications can't cross-interact. If you use runas to run GUI applications under different user contexts, you might notice that some things like drag-and-drop and the clipboard don't work, and also screen recorders won't work ... Most users never use this functionality normally, but you might notice sometimes if you do "Run As Administrator" and the applications don't quite integrate with non-admin apps.

Oh, so that's how this works. I've noticed this through occasionally broken copy-paste between normal and "elevated" apps. Never realized it's a separate feature, not just a forced sandboxing between regular and "elevated" apps. Thanks!

In store applications without full trust permissions you can not.

Store applications are not the only applications on Windows 10. Closing holes in store applications alone does not close all the holes.

This article is addressing sandboxed applications.

Regular applications, yes, you can pretty much do whatever in userspace in Win/Mac/X11. If you're going to create a new sandbox environment for applications (Windows Store/MacOS store) in today's world, it really needs to be locked down with explicit permissions for each type of I/O access.

On Linux, Wayland fixes this (+ allows for other security features, e.g. to protect the clipboard).

You can trivially sandbox X11 apps by running them in a nested X server.

And a separate user account, otherwise they can just connect to the original X server. (And on almost all existent Linux systems, either running as a separate user isn't trivial or the sandboxing process has root.)

Is a separate user account necessary if the Xauthority cookie is shadowed in the sandbox? I think firejail's nested X server setup works this way, without a separate user account.

What prevents you from reading the Xauthority cookie out of disk / an existing process's environment / out of an existing process's memory / etc.? You need a sandbox to prevent it fro doing these things, which is certainly doable, but much harder than just opening a new X server.

(On a system without Yama enabled, you can also ptrace any other process running as the same user and run code as it, e.g., using gdb, but lots of desktop-focused Linux distros enable Yama to close this particular approach.)

> What prevents you from reading the Xauthority cookie out of disk / an existing process's environment / out of an existing process's memory / etc.?

The sandbox does.

> You need a sandbox to prevent it fro doing these things, which is certainly doable, but much harder than just opening a new X server.

Of course. I never said simply running a new X server is sufficient. All I asked is if the sandbox needed to run the program in a separate user account.

How many apps do this?

If you trust an application so far as to properly limit itself in what it can do by requesting a sandboxed environment so you don't have to type a few additional letters you might just as well run it without a sandbox.

Hey kind stranger who is supposed to do the garden while I go shopping, I really don't trust you. So to be sure you only do the garden and nothing else, here are the keys to my house, please ensure that every door and window is locked. Thanks.

The only other entity who could set it up for you, so every application automatically launches in a sandboxed environment, is the distributor, but then again it's your responsibility to chose a distribution that does that.

If you want security you have to do something about it at one point or another.

I think this is the wrong attitude. No one is better suited to implement a sandbox than the developer of the application. The fact that most developers are not trained to do so is just a reflection of our field's terrible progress re: education devs on secure app dev.

Leaving this to the user leaves the vast majority of users unsafe. This is an unacceptable state.

Why should an application developer implement a sandbox? That's a huge waste of time and it's much more efficient if the operating system or the user enforces it instead by using existing sandboxing technologies like firejail. It is also untrustworthy and insecure, since after all you don't trust the application. If an application is responsible for sandboxing itself it can also choose not to sandbox itself properly if it wants to do harm.

There is no way around you either taking care of that yourself or you choosing an operating system that enforces it for you, like Qubes OS.

> Why should an application developer implement a sandbox?

Because they are the ones who understand the necessary capabilities of their program and the ones who have access to the source code...

> That's a huge waste of time and it's much more efficient if the operating system or the user enforces it instead by using existing sandboxing technologies like firejail.

Actually it's a far better sandbox when built into the program. And it doesn't leave users relying on installing arcane operating systems or becoming technically savvy.

> It is also untrustworthy and insecure, since after all you don't trust the application.

No, trusting the application is implicit since it's installed by the user. The sandbox exists to protect against a compromised application.

I, the user, do that. It's not the app's responsibility.