The thing about being able to read other process memory under Linux has always driven me nuts. Linux is fairly secure _except_ for this one giant gaping hole that nobody mentions.
On a rolling release like Debian Testing, with well-supported hardware like the Intel Ivy Bridge integrated GPU, WebGL has always worked beautifully.
I bet it comes down to driver developers never even thinking that this could be a security issue before people came up with the concept of running unauthenticated 3d accelerated software (i.e. javascript+webgl from the network in a browser) - "what do you mean security, the user could just have taken a screenshot at any time. why should we waste precious FPS clearing buffers when the program will fill in its own textures before drawing anything".
gdb, when using it to attach to an already running process.
GO.COM contained no program bytes at all – it was entirely empty. However, because GO.COM was empty, but still a valid program file as far as CP/M was concerned (it had a directory entry and file-name ending with .com), the CP/M loader, the part of the OS whose job it is to pull programs off disk and slap them into the TPA, would still load it!
So, how does this help? Well, using the scenario above:
the user exited WordStar the user ran DIR (or whatever else they needed) and at some future point would be ready to re-run Wordstar the user now ‘loaded’ and ran GO.COM the loader would load zero bytes of the GO.COM program off disk into the TPA – starting at address 0100h – and then jump to 0100h – to run the program it just loaded [GO.COM]!
result – it simply re-ran whatever was in the TPA when the user last exited to DOS – instantly"
It also wasn't unusual to try and recover data from memory after a program crashed by launching a small program that dumped memory to disk. 100% reliable? No, but it was the best one sometimes had.
SAVE 0 X.COM
The trouble is that it's a sort of retrofitted check. It works surprisingly well, but being added to a 20+-year-old OS and a 40+-year-old design, it can't guarantee being correct. The traditional, historic process boundary on UNIX has been user accounts / UIDs. Desktop Linux needs to figure out a way to do what Android does, and run every application with a separate UID, including the ability to have private files that are unreadable to other applications.
The challenge is defining "application". Android, being a greenfield platform, could define the interaction between applications. On desktop Linux, it's obvious that, say, a web browser and a PDF viewer should be different applications. The two processes in a "find | grep" shell pipeline probably should count as the same application. In between, it's pretty blurry, because we've had 40 years to develop patterns that don't account for this isolation ever happening.
Not completely obvious. The web browser could use the PDF viewer to render PDF and/or the PDF viewer could use the web browser to run JavaScript embedded in a PDF file (http://www.adobe.com/devnet/acrobat/javascript.html). Both examples are similar to your find|grep example.
Yes, that typically would be done by reusing libraries, not by starting processes, but modern browsers run a separate process per tab and some run flash in a separate process. Running a PDF viewer in a separate process would be a logical extension.
Unfortunately, it does absolutely NOTHING with regard to OpenGL isolation :( (That is if you give programs permission to talk to the graphics card, which is denied by default...)
Have you looked at OpenGL virtualization e.g. Virgil (https://virgil3d.github.io/ , https://www.kraxel.org/blog/tag/virgl/) for that problem? The idea is to use Gallium to give them just enough access to get host 3D acceleration, but not direct access to the graphics card.