Puzzle: Adding domain-based security to Squeak.

Howard Stearns hstearns at wisc.edu
Mon Aug 7 14:29:54 UTC 2006


Michael,

In my opinion, you're solving the wrong problem. Fun, perhaps, but not 
likely to help you win big. (FWIW, IMHO, YMMV, etc...)

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?

I imagine that there must be a lot written in or about the Java 
community that gives examples of this. But in short, since users and 
administrators don't know whether or how much to limit 
non-behavior-oriented computer resources, they are forced to either 
trust an application completely, or to restrict it pretty-much 
completely, which makes it fairly useless. There is a  better way.

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.

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

-Howard

Michael van der Gulik wrote:
> Hi all.
>
> Here's a generic problem for people that like puzzles that I can't 
> seem to work out: I want to add "Domains" to Squeak, so that system 
> resources can be managed.
>
> Here's how it would work, in theory:
>
> * A domain would typically be a group of objects related to a 
> particular application.
> * Every object belongs to a domain.
>
> And then:
>
> - A domain's memory usage can be capped. Object>>new would be 
> implemented so that it would wait for free memory or throw an 
> Exception if the memory cap has been breached.
>
> - A domain can only start up a limited number of Processes. This would 
> control fork bombs etc. Process>>new or some other entry point would 
> check for this and wait or throw an Exception if the process limit has 
> been breached.
>
> - Ditto for other system resources, such as disk usage, network 
> bandwidth, access to devices etc.
>
> - I'm implementing a distributed system, so remote objects that come 
> in will already belong to a particular domain. A local DomainManager 
> or some other mechanism would determine if objects from that domain 
> are allowed to use local system resources, and at which priorities.
>
> For example, I could have two domains: "AlicesEmail" an "BobsEmail". 
> AlicesEmail is capped at 10Mb of memory and 6 processes. BobsEmail is 
> capped at 20Mb of memory and 15 processes. Assuming that the Squeak 
> image is a remote mail server; now neither Alice nor Bob can make the 
> image explode by doing funny things with their email. Both domains use 
> the same classes.
>
> Now, here's the problem:
>
> How would I implement Object>>new and Process>>new (or other equally 
> good locations) so that the domain for that object is found and a 
> DomainManager queried about that domain's privileges?
>
> The possibilities that I've thought of so far are:
>
> 1. Adding an instance variable called 'domain' to Object is a bad idea 
> - consider SmallIntegers and parts of the VM that assume certain 
> instance variables are in certain places.
>
> 2. Creating dictionaries of which objects are in which domains would 
> work, but is going to be extremely inefficient. _Every_ object in the 
> image would have an entry in these dictionaries.
>
> 3. Creating a subclass of Object with an instance variable "domain" 
> could work, and then all other objects that are used by domain-using 
> code are subclasses. I'm still thinking through the implications.
>
> 4. Assigning domains to processes rather than objects is a 
> possibility, but this would allow resource theft when invocations are 
> done on objects out of the current domain. If this was done, the 
> current domain would just be <<thisContext domain>>.
>
> 5. Another option is to make radical changes to the VM, so that a 
> domain of objects are all kept in the same range of memory. This would 
> be a rather major change and would introduce bugs.
>
> 6. I could do fancy tricks with the garbage collector like 
> ImageSegment does and trace references back to an object which 
> identifies the current domain. This is slow and yuck.
>
> So far alternatives 3 or 4 seem possible.
>
> Thinking aloud; option 4 could be implemented by implementing 
> Domain>>doPrivileged: taking a block as an argument. Object>>new and 
> Process>>new can then search down the stack until 
> Domain>>doPrivileged: is found and ask the global DomainManager what 
> that domain is allowed to do. Calls out of the current domain can be 
> stripped of privileges by doing something like 
> noPrivilegesDomain>>doPrivileged: [otherObject doSomething]. 
> otherObject would then need to call doPrivileged: again with its own 
> domain to regain the ability to fork and make new objects.
>
> Umm... this would need some way of preventing user processes from 
> peeking down the stack and stealing another domain (i.e. using 
> capability-based security).
>
> Option 3 has the advantage of making less work for the poor 
> application developer, but incurs an extra pointer for every single 
> object.
>
> Java does something similar, but it does it based on classes or jar 
> files (afaik). This is not particularly good - you can't have two 
> domains with different privileges which share the same implementation. 
> For example, you can't have an "AlicesEmail" and "BobsEmail" domains 
> with different privileges if they both use the same classes.
>
> Thoughts? Does anything like this already exist?
>
> Mikevdg.
>
>

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




More information about the Squeak-dev mailing list