Puzzle: Adding domain-based security to Squeak.
David T. Lewis
lewis at mail.msen.com
Wed Aug 9 10:51:30 UTC 2006
On Tue, Aug 08, 2006 at 09:29:00PM +0100, Michael Roberts wrote:
>
> On 8 Aug 2006, at 10:03, 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.
>
> This is not exactly what you asked for, but -
>
> as an experiment why not run your untrusted code in a separate
> image? If you were running this on unix then you could limit the
> memory given to this separate image - either via say ulimit in the
> shell or something fancier (maybe via the os process plugin). You
> could then talk to the 'jail' image via remote messaging. It
> wouldn't take very long to knock up and it might give you interesting
> results early.
An easy way to do start the remote images is UnixProcess class>>forkSqueakAndDo:,
but you'll want to do something to make sure the remote images are not
writing to their original changes file, otherwise you'll have a swarm
of images all scribbling on the same changes file.
If the remote images are short-lived and do not do things that result
in a lot of garbage collection, then the overall memory usage is
surprisingly light. I presume that this would do reasonable things
on a multiprocessor system also, although I don't have a system to
try it on.
Dave
More information about the Squeak-dev
mailing list
|