Walter did yo realy go Ohhhh?

[Yigal Chripun]

Nick Sabalausky wrote:
> "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.
> 

yep

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

not exactly the same thing. the major difference is this: with
users/roles/groups/rules/ACLs/etc.. the security is separate from the
code. see explanation below.
> 
> 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!"
> 
the concept of users in the system is implemented /on top/ of the
Capabilities mechanisms in the kernel (or actually a micro-kernel to be
precise). The Kernel has no concept of users at all, this is all
implemented in user space.
think of it like this: processes on the system are entities that have
certain capabilities. they can exchange those capabilities with each
other. users would be implemented in that system also as entities (of a
different kind) that can have the same capabilities.  This means that
security is implemented at a lower level.

Here's a snippet from the relevant article on wikipedia:

suppose that the user program successfully executes the following statement:

    int fd = open("/etc/passwd", O_RDWR);

The variable fd now contains the index of a file descriptor in the
process's file descriptor table. This file descriptor is a capability.
Its existence in the process's file descriptor table is sufficient to
know that the process does indeed have legitimate access to the object.
A key feature of this arrangement is that the file descriptor table is
in kernel memory and cannot be directly manipulated by the user program.