Look into Code Access Security (CAS) in .NET - it is a pretty damn tough security sandbox; every operation that can be called in the default libraries is security rated; everything outside that is weighted based on: - What it declares itself - What functions in the Standard Library it calls (can only be as secure as all the functions it calls) - If it uses native code (automatically 'unsafe')
>From what I understand, Mono ended up implementing a lot of that for >Silverlight; although I do not know how the security holds up compared to the >official .NET runtime; but AppDomains + CAS is a pretty rock solid sandbox on >Windows. Regards, Adam > -----Original Message----- > From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource- > dev-boun...@lists.secondlife.com] On Behalf Of Argent Stonecutter > Sent: Thursday, 18 February 2010 5:46 AM > To: Morgaine > Cc: opensource-dev@lists.secondlife.com > Subject: Re: [opensource-dev] Client-side scripting in Snowglobe > > 7. 8. 9. 10. ... I'm not going to run client-side scripts if I can't > eyeball them. Creating a sandbox is a huge, complex, and difficult > job, even in an application designed to run untrusted content from the > ground up. Putting a blind scripting environment inside something like > the SL client is risky. Putting one that isn't inherently secure in > there is scary. > > Linden Lab does not trust the Mono sandbox on the server: you can't > upload Mono bytecodes like you could LSL bytecodes. And they > shouldn't. LSL bytecodes are run in an inherently secure > environment... they can not perform any operation outside the > capabilities of the LSL runtime: security and access controls are > implemented outside the interpreter. Javascript and Activescript in > Flash are in the same situation: they are languages that can (and > usually do) run in an interpreter that does not even implement unsafe > operations. Java and Mono/.NET intermediate language can do anything > native code can, they are not inherently secure, and should not be > treated the same way. * > > Even if the entire viewer was run in a provably secure virtual machine > this would not seem like a safe option to me, since the viewer has > full access to all my assets and account information in Second Life. > > Now there are situations where this kind of assembly would be > acceptable, where it's treated and presented to the user as an > application, where the user has to explicitly request that it be > installed, where it is made clear that installing a plugin is the same > kind of risk as installing and running an application. But not when > it's something that can be pushed from an untrusted source with no > more than a warning dialog between you and HonestImNotInThePN > ThrowawayAlt. > > Even if they were using an inherently safe language, accepting > unexaminable binary payloads from untrusted sources and running them > in the SL client in anything like its current state would raise all > kinds of warning flags with me. Doing this using an internally- > sandboxed interpreter just isn't something I'm prepared to do. > > * No, I don't use Silverlight and I have Java disabled. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
