Imagine that a magic fairy comes and creates a system that works exactly 
as you prescribe.
 
    Now, how will you or your users guess that 64MB RAM / 100MB disk / 
100MB traffic/day is appropriate for one application, while others use 
different figures? It's like Windows asking me whether I want to use 
extended memory or a fat file system during installation. How the hell 
should I know? And why wouldn't some domains want to restrict KB 
traffic/second instead? Or the number of open connections? Or how much 
second-level cache is devoted to Processor 1 vs Processor 2? Or....etc. 

   Alright, now imagine that the same magic fairy (let's call it a 
"Wizard") comes and gives you a dialog box that's going to make it easy 
to configure these possibilities, or better yet, picks a magic right 
answer for each.  What problem have you solved? Have you now made your 
computer safe against viruses, malware, or poorly designed software? 
Have you made the applications in these domains now easy to operate, 
fast, and robust. (Answer: no.)

   Now consider two applications in two different domains communicating 
with each other....

My point is that I believe that sandboxing applications into 
resource-starved ghettos may be technically fun to program and you may 
learn a lot of neat stuff. But when you look at the whole end-to-end 
problem, it isn't going to produce the result of "allowing untrusted 
foreign code to run in the same image as trusted code." Java has already 
demonstrated this to be the case.

Here's some hand-wavy heuristics:
 - Don't ask the user to configure stuff that they don't know about. 
(Assume administrators don't know about pretty much the universal set.)
 - Don't try to make low-level infrastructure do something that it can't 
do completely or correctly without application knowledge, such that the 
application ends up having to do it itself anyway.
 - If you want to aggregate stuff (e.g., for ease of administration), 
then create a basic mechanism that handles the fine grain (e.g., 
capabilities) and which can be fractally applied at different scales. 
Creating a the aggregated thing first (e.g., access control lists) tends 
to break down when you run into the real-world special cases, and then 
you end up with two half-broken mechanisms.
 - Don't spend a lot of effort implementing a feature that doesn't 
actually deliver a result that the user can see. (E.g., Putting a 
stoplight up on Bagdad's airport road may make it a little safer with 
respect to traffic accidents, but that's not actually the major safety 
problem.)

Michael van der Gulik wrote:
> Hi Howard.
>
> I forgot to mention that the reason I'm doing this is to allow 
> untrusted foreign code to run in the same image as trusted code. 
> Untrusted code must be carefully managed - it must not be able to 
> consume large amounts of memory, CPU or disk space to which it is not 
> entitled. Untrusted code / objects must not prevent trusted code from 
> operating well.
>
> Oh, and Squeak is full of security holes, but there will be ways to 
> patch them I'm sure.
>
> Howard Stearns wrote:
>> It seems to me that any attempt to put arbitrary, coarse-grained 
>> restrictions on computer resources -- as opposed to problem-domain or 
>> user-domain behaviors, is just doing a lot of work to shift the 
>> problem, without actually solving it.  How will the programmer set 
>> these limits? How will the poor user or "administrator" manage them?
>
> The programmer, user or administrator will manage them "manually"; 
> coarse-grained restrictions are course-grained, meaning that there 
> aren't many of them.
>
> Example: You find a foreign set of objects and classes in a domain 
> called "SqueakSeti at home" and decide to grant that domain access to you 
> local computer: it is granted low-priority CPU only, memory is bound 
> to 64MB, this domain may use 100MB of disk space and no more than 
> 100MB of network bandwidth per day.
>
> Meanwhile, another domain called "ImportantBusinessStuff" can use 
> high-priority CPU, no more than 256MB memory (i.e. the size of 
> physical memory), etc.
>
> This all makes a lot more sense when working with a public distributed 
> system where code and objects float from computer to computer. In this 
> case, a group of distributed objects are all bound to a "Domain", and 
> individual computers decide how much privilege that Domain has on each 
> computer.
>
>> Now, there are two issues:
>>
>> 1. "But my customer wants to do it the broken way!" Fair enough. You 
>> might consider, though, whether or not this approach fits with the 
>> real advantages (to the customer, not to you) of using Squeak. If you 
>> turn the application into something that works just like Java except 
>> that it's in Squeak, you can bet the contract that in the end, the 
>> customer will decide to re-implement it in Java (for social reasons, 
>> such as covering their butts in deploying, hiring people to work on 
>> it, etc.)  Doing a broken, Java-like thing "better than Java" is just 
>> a special case.
>
> Umm... I don't get your point. This is for my own project. No 
> customers, no Java.
>
>> 2. "OK, How SHOULD I do it?" Here you have to look at the actual 
>> problems you're trying to avoid. For example, suppose you want to 
>> keep mobile programs from writing files on a user's computer. The 
>> answer is to arrange to only present a 'file open' interface that 
>> prompts the user for the location. 
>
> ...like a capability.
>
>> This is better than draconianly prohibiting all 'file open' requests, 
>> because it still allows arbitrary programs to do useful work as long 
>> as the user is made clearly aware of what the program is doing. (In 
>> an imperfect-world nod to resource management, that user dialog might 
>> specify the max size of the file.)  Now suppose you want to have the 
>> system manage (e.g., remember) the fact that such-and-such an object 
>> has requested a file-open, and that the user has granted it for given 
>> name/size. The capabilities community (see e-rights) has a lot of 
>> literature on how to do this securely. But as I see it, the 
>> capabilities stuff is just an implementation detail for the 
>> higher-level issue of  choosing what (or where) to manage 
>> problem-specific behaviors. (See end-to-end argument.)
>
> That's what I intend to use domains for... they're a higher-level 
> "management object" to manage problem-specific behaviours.
>
> A reference to a File object would be a capability. The "Domain" 
> aggregates objects together so that permissions can be granted in 
> bulk. Objects that need access to that File object (which is a 
> capability) would ask their Domain instance for it. If the Domain 
> instance does not have it, access is obviously not possible.
>
> Of course the implementation details might end up different, but the 
> idea is that the local system grants Domains the rights to use system 
> resources.
>
> Michael.
>
>

-- 
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:hstearns at wisc.edu
jabber:hstearns at wiscchat.wisc.edu
voice:+1-608-262-3724