No subject

light; although I do not know how the security holds up compared to the off=
icial .NET runtime; but AppDomains + CAS is a pretty rock solid sandbox on =
Windows.

Regards,

Adam

> -----Original Message-----
> From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-
> dev-bounces at lists.secondlife.com] On Behalf Of Argent Stonecutter
> Sent: Thursday, 18 February 2010 5:46 AM
> To: Morgaine
> Cc: opensource-dev at lists.secondlife.com
> Subject: Re: [opensource-dev] Client-side scripting in Snowglobe
>=20
> 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.
>=20
> 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. *
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> * 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