Walter did yo realy go Ohhhh?

[Georg Wrede]

Yigal Chripun wrote:
> 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.

If the code that gets run "as the user" is malicious, and there are no 
additional guards, then the code could chmod any read-only file you have 
and then edit it, according to its malicious goals. In practice, these 
additional guards constitute the Sand Box.

> 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.

Not on my servers, they don't. I rely solely on user/group stuff. And I 
find it adequate.

> that's why apache runs with user www-data with
>  its own ACL rules.

Apache has run as "www-data" or whatever, since the beginning of time, 
and that has been because it is natural and "obvious" to give the WWW 
server its own identity.

> you can achieve perfect security with this scheme if
> you invest enough time to create a separate "user" for each process. 

If this were so simple, then we'd have no issue with this entire subject 
-- for the last 5 years.

To put it another way, if the WWW server could run every user's code as 
a separate OS user, then of course things would be different. But the 
average Unix (Linux, etc) only has 16 bits of information to identify 
the "user". And sites like Google have users in the Billions. So, it's 
not a viable option.

> 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.

Server and client problems should be kept separate in one's mind set.

> it's easy to see all the problems with manually defining ACLs.
> Newer OSes based on the concept of "capabilities" remove all those
> problems.

"All those problems". You've been listening to marketing talk.

> 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).

I was the Oracle DB Head Administrator in the early '90s at a local 
University. The concept of Roles was introduced then by Oracle. I 
actually got pretty excited about this. Instead of Mary, Jo-Anne, and 
Jane all having their respective read, write and update rights, I could 
define Roles (which is pretty near the Capabilities concept), so that 
Updater of Student Credits, Updater of Student Addresses, Updater of 
Class Information, etc. could all be defined, and when any of the girls 
went on holidays, I could simply assign the Role to the back-up person, 
instead of spending days on fixing read-update-write rights for 
individual table columns and/or views.

> 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.
...
> No sandboxes/VMs/any other emulation layer is needed.

Gee, nice.

Still, D has to relate to what's going on today.