Walter did yo realy go Ohhhh?

[Nick Sabalausky]

"Yigal Chripun" <yigal100 at gmail.com> wrote in message 
news:g3ekcq$82e$1 at digitalmars.com...
> Georg Wrede wrote:
>> Yigal Chripun wrote:
>>> could you explain please why there's a need for a sandbox in the
>>> first-place?
>>
>> OS security protects the system and the other users from you.
>>
>> A sandbox protects you yourself from code that's run "as you".
>>
>> (That is, protects your files, etc.)
>
> I disagree. OS security can and does protect the user's files from code
> that's run "as the user" <-this is a bad concept.
>
> current OSes use ACLs (windows, linux, etc..) and there's nothing
> stopping you from defining a file to be read only, or non-executable to
> protect data, and the current practice is to define "users" for deamons
> in order to protect data. that's why apache runs with user www-data with
> its own ACL rules. you can achieve perfect security with this scheme if
> you invest enough time to create a separate "user" for each process.
> as an example, I can run my browser as a different limited user or use a
> browser which runs inside a sandbox. I can get the same protection from
> both but the sandbox solution has more overhead.
>
> it's easy to see all the problems with manually defining ACLs.
> Newer OSes based on the concept of "capabilities" remove all those
> problems. such OSes give processes defined capabilities unrelated to any
> concept of a user (the concept of users is defined on top of the
> capabilities mechanism).
> Capabilities are basically the same as OOP - simplified example:
> currently OSes are written in a procedural way, there are global data
> structures and global system calls. i.e. you print to screen via
> Stdout(text); in D which just calls in the end the appropriate syscall.
> in a capabilities based OS, there is no such global syscalls/functions.
> you need to hold an output instance (a handle in the OS - a Capability)
> in order to call its print method. only if the process has that instance
> it can print to the screen. security is implemented via the explicit
> passing of such instances. so if the program received an output
> instance, it received the right to print to the screen.
>
> No sandboxes/VMs/any other emulation layer is needed.
>
> --Yigal

If I understand all this right, it sounds like this is how it works within 
the context of browser plugins and applets embedded in a webpage (ie, 
something like Flash/Java Applet/ActiveX):

Old (current) way:
A browser is run as user X. Thus, the browser can do anything user X can do. 
A browser plugin, by its nature, can do anything the browser can do (read 
locally stored webpages, read/write cookies cache and browser history, 
delete everything in /home/userX, etc). So to prevent a malicious webpage 
from embedding something that...well, acts maliciously, there are two 
options:

1. The browser plugin has to *be* a sandboxing platform like Flash or Java 
Applets, but unlike ActiveX. This plugin/platform is trusted to not expose 
unsafe things to the applets running inside of it.

2. (Better) The browser sets up a special limited-rights user for 
plugins/applets (or optionally, one for each plugin/applet, for 
finer-grained control). The plugin/applet is run as this limited rights 
user.

New way:
Sounds like basically the same thing except replace "user X" with "a few OS 
handles", and "browser creates 'browserPlugin' user" with "browser 
selectively passes its own OS handles to the plugins as it sees fit"?

And I suppose you configure the OS to grant/disallow these handles in more 
or less the same way user rights are currently granted? Except they're 
granted to programs in addition to/instead of users? And I'd assume you'd 
still need some sort of ACLs so a program can't just go, "Aha! I need to 
open/save files, so I got a 'write file' handle and a 'read file' handle! 
Now I can use those handles to read all of the person's private data and 
overwrite the system files with pictures of potatoes!"