From: Lex Spoon [mailto:lex@cc.gatech.edu] It's easy to make a modified compiler which removes booboos like this. Things to remove:
- <...> primitives
- thisContext
- access to the full Smalltalk dictionary
Having done something this to nail down VisualWorks...
4. Ability to modify the Compiler. 5. Ability to create your own Compiler. 6. Ability to instantiate arbitrary classes and therefore create your own methods and fill 'em with bytecodes. 7. Ability to become: on methods to swap 'em for others that you've created and are waiting in the wings. 8. Debug primitives such as instVarAt:put:
It is *not* easy. Anything but. I was trying to do the more restricted form of preventing users seeing source code to which they didn't have access; that was messy enough. It's a whole lot harder when you have ways of generating and dumping arbitrary bytecodes into your system.
Given the choice, I'd certainly go for removing 'dangerous' primitives --- and ensuring that no part of the remaining run-time system used those primitives, which could be fun.
But in return, you get a much more flexible system. Your proxies can invoke arbitrary Smalltalk code as they make their decisions. You security policies can be implemented in Smalltalk code instead of C, so that you can easily do complicated things like consulting network databases.
I agree that it is more flexible, but it is also *much* harder to verify. Crackers are still able to get at functionality provided they can find an appropriately tortuous route through the proxies. I'd be much happier running an unknown Squeaklet on a VM with its I/O primitives removed or crippled than I would on a fully-functional VM with image-level capabilities.
- Peter
P.S. Should I admit I've been on the software cracking side in my time?