Walter did yo realy go Ohhhh?

[Yigal Chripun]

Nick Sabalausky wrote:
> "Yigal Chripun" <yigal100 at gmail.com> wrote in message 
> news:g3gltb$1b4a$1 at digitalmars.com...
>> 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.
>>
> 
> Ok, I think I'm starting to get it, but I'm still a little fuzzy on some 
> stuff (for clarity I'm going to use the terms "human user" and "OS user" to 
> disambiguate what I mean by "the user". Human user of course being the 
> actual person, and os user being the os's concept of a user):
> 
> Suppose I'm writing a hex editor for one of these capabilities-based OSes. 
> I've got to be able to read/write various files.
> 
> Non-capabilities way:
> The human user runs my app. The app is run as either OS user "userX", or 
> some special OS user that the program was configured to run as. The human 
> user tells my app, "Open file 'fileX' (passed by filename)". My app then 
> says to the OS, "Open file X for me, based on the credentials of whatever OS 
> user I'm being run as". The OS then looks up the ACL info and grants/denies 
> access accordingly.
> 
> Capabilities way:
> The human user runs my app. The human's OS user object (name of this object 
> is 'userX') is passed to my app kinda like a command line paramater would 
> be. The human user tells my app, "Open file 'fileX' (passed by filename)". 
> My app then *doesn't* talk to the OS, but instead goes to userX, 
> "userX.openfile(fileX, whateverAccessLevel)". If the OS user has that 
> capability and is willing to give it to my app, then it returns the 
> appropriate capability. If the OS user doesn't have that capability then it 
> requests it from whatever its authority is (who? The OS?), just like how the 
> app requested it from the OS user. Somehow, the OS user's authority (if it's 
> successfully able to retreive access from its authority) decides whether or 
> not to allow userX access (I still can only imagine this part involves come 
> sort of ACL or ACL-equivilent).
> 
> 

first a wikipedia link: http://en.wikipedia.org/wiki/Capabilities
now let's try to figure the second way:
let's define a system with 3 users: root, userA, userB. from a security
POV those are 3 entities with caps [I'll use that inteas of typing
"cappabilities"].
userA has all caps [view, edit, accessGUI] for image file A, and a play
cap for audio file B.
when the real person runs a gimp process on file A as userA the gimp
process receives the user's caps on creation. the gimp process can use
the edit cap to edit file A, and show the changes on screen via the
accessGUI cap.

in your example think of userX as a list of caps. when your human user
runs the app it runs it with app.run(listOfCapsForApp) {that's pseudo code}
the app doesn't know or care about the user. it has a list of caps. on a
 *nix system you can include header files and call syscalls which are
just global functions provided by the OS. with caps, the headers define
something like classes [which in turn need to receive a different set of
caps to create an instance of themselves]. your app can get a File cap
(which is an OS object instance) that define the relavant syscalls as
methods on that object. so instead of:
openfile(fileX, whateverAccessLevel)
you get a fileX from the user and do a filex.open()
you do not pass the accessLevel to Open, since the fact you have that
fileX reference in your app implies you already have the needed access
level to use its methods.

instead of separate access rules, think of it like this:
if you do not have a fileX object than you cannot do anything on that
file. if you have a fileX object, you can use all it's methods.
if you have an invariant fileX (if I use the D terminology) than you can
only use the invariant methods.

The system has a predefined set of caps when booted. you can use those
caps to create more caps and pass those to different processes, and so
on.. the UI can translate user actions to caps - for example: you can
think of opening a file in a dialog in your editor app as [implicitly]
providing the process a cap to that file. if you have only read-only
access to the file (as defined in your OS user) than you can only give
the process a read-only cap.

one last note: caps allow you to limit behavior of processes - even if
your MP3 file contains a virus that deletes all your files, you can
safely play it since the player only has a cap to play that file, and
cannot run arbitrary code on the system (even if you run the player as
root!) since the player process doesn't need any concept of a user to
work and it only cares for the caps it currently has.