On Tue, Jan 28, 2003 at 11:41:14AM +0000, Thomas Whateley wrote: > Hi, > > I've been thinking about how to run un-trusted code, > without having to audit every line, or use some sort of sandbox, > and was wondering if Parrot could provide a Mandator Access > Control mechanism (ala SE Linux/Flask). > > When assembling Parrot, the assembler could either look in a > file or a perl BEGIN type block containing a list of access > requests along the lines of: > > syscall time > read-write directory /tmp > listen socket 80 > connect socket 25 > read-write file /etc/shadow > > If people think something like this would be usefull, I'd be > more than happy to research this further and try to come up > with some code....
It would be immensely useful, especially for online, distributed games, in addition to general sysadmin paranoia. I'm very interested in this. It reminds me of the capability systems. I'm admittedly pretty culeless when it comes to this stuff, but it's one of the reasons I really want Parrot to succeed. Of course, doing this on the parrot level brings up some interesting issues; how exactly do we define what needs to be restricted in case of untrusted code? I'm inclined to say "All classes", because a white list is really the only sane way to do security, with defaults being classes that are deemed harmless. Also, I think that this should be made as dynamic as possible so different languages/applications can plug in to the security system to overload certain things (intentionally vague here). One other thing to think about is resource limits. It'd be nice to not require `ulimit' or whatever system-specific resource limitation mechanism, but rather rely on the parrot interpreter to baby-sit. Also, it'd make catching these resource-limit violations much more convenient; an exception could be raised (or, e.g., the rate at which bytecodes are executed could be throttled), rather than simply rudely killing the process. For what I want to do, it's not really required, and it's not really relevant to the type of security we're discussing here, but it would still be very, very useful. Some incoherent ramblings of mine about secure distributed code in virtual worlds: http://twistedmatrix.com/users/radix.twistd/Distributed_20Games A really cool research-project language, "E", which is all about capabilities: http://erights.org/ CapDesk, a slightly irrelevant but very interesting design for capability UIs: http://www.combex.com/tech/index.html -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://twistedmatrix.com/users/radix.twistd/
