August 22, 2001
In article <3B829F9C.6CF8F3D9@deming-os.org>, Russ Lewis wrote:
> 
> In my opinion, the VM (if Java was limited to it) *would* solve all problems.  The real problem you're describing is not that the VM doesn't work, but that the VM has hooks that allow you to get outside of it.  A D compile-time sandbox would not have to have these kinds of hooks.

If I have pointers, and you compile the code to native machine code, chances are that I can get around any sandbox not created by the OS.

--Toby.
August 22, 2001
Tobias Weingartner wrote:

> In article <3B829F9C.6CF8F3D9@deming-os.org>, Russ Lewis wrote:
> >
> > In my opinion, the VM (if Java was limited to it) *would* solve all problems.  The real problem you're describing is not that the VM doesn't work, but that the VM has hooks that allow you to get outside of it.  A D compile-time sandbox would not have to have these kinds of hooks.
>
> If I have pointers, and you compile the code to native machine code, chances are that I can get around any sandbox not created by the OS.

Please read my original post.  I stated that in "sandbox" mode the D compiler would have to generate runtime checks of all pointer dereferencing, and that it would have to keep a table of all allocated memory so that it knew which pointers were valid or not.  The user would choose to pay the penalty for these features in order to ensure that the program could not have wild or malicious pointers.

August 22, 2001
In article <3B83E9D5.99A2BEAD@deming-os.org>, Russ Lewis wrote:
> 
> Please read my original post.  I stated that in "sandbox" mode the D compiler would have to generate runtime checks of all pointer dereferencing, and that it would have to keep a table of all allocated memory so that it knew which pointers were valid or not.  The user would choose to pay the penalty for these features in order to ensure that the program could not have wild or malicious pointers.

The chances of me getting around that with some user supplied input are *very* high.  Realisticly, given pointers, buffers, and functions is all one needs.  (And *maybe* 1 very tiny, small mistake in the compiler).

--Toby.
August 22, 2001
Tobias Weingartner wrote:

> In article <3B83E9D5.99A2BEAD@deming-os.org>, Russ Lewis wrote:
> >
> > Please read my original post.  I stated that in "sandbox" mode the D compiler would have to generate runtime checks of all pointer dereferencing, and that it would have to keep a table of all allocated memory so that it knew which pointers were valid or not.  The user would choose to pay the penalty for these features in order to ensure that the program could not have wild or malicious pointers.
>
> The chances of me getting around that with some user supplied input are *very* high.  Realisticly, given pointers, buffers, and functions is all one needs.  (And *maybe* 1 very tiny, small mistake in the compiler).

Sure, compiler bugs are one thing.  But I don't understand - other than an exploit of a compiler bug - how any sort of user interface could get around this type of lockdown.

August 23, 2001
"Russ Lewis" <russ@deming-os.org> wrote in message news:3B829F9C.6CF8F3D9@deming-os.org...
> I think that both of you (Johan and Richard) are missing what I mean.
>
> I fully understand that D cannot create a *runtime* sandbox without
implementing
> a Virtual Machine, and even then it's iffy.  What I'm suggesting is a *compile-time* sandbox.  (see responses below)
>
> [...]
>
> What I'm envisioning is a situation where people can freely and safely
trade
> simple plug-in applications, provided that they don't mind the overhead of running them in the compile-time sandbox.
>
> I'm an avid game player.  I want to be able to develop AIs for the games I
play,
> but even the most extensible ones rarely have more than text files where I
can
> tweak parameters.  I want to be able to write a D module that implements a certain AI API, then dynamically link it into the game.  When I like it, I
post
> the source on the web for other users in the community to try.  They don't
have
> to worry if I am a malicious programmer (or even just a bad one); they
trust the
> compile-time sandbox.

Oh - maybe I get it.

I'm suddenly reminded of Quake III.  Game mods are programmed in plain C, and are downloaded automatically from the game server to your box when you start.

"Are you serious?" I hear you cry.  What a potential virus nightmare!

Yes, it would be, except that what gets downloade is C *source* code, not compiled native code.  The source code is compiled by Quake's special LCC-derived compiler, which presents it with only a limited in-game API, and specifically *not* the full platform API.  It also removes some of C's feature set, like the ability to call through a function pointer.




January 27, 2002
"Russ Lewis" <russ@deming-os.org> wrote in message news:3B829F9C.6CF8F3D9@deming-os.org...
> I think that both of you (Johan and Richard) are missing what I mean.
> I'm an avid game player.  I want to be able to develop AIs for the games I
play,
> but even the most extensible ones rarely have more than text files where I
can
> tweak parameters.  I want to be able to write a D module that implements a certain AI API, then dynamically link it into the game.  When I like it, I
post
> the source on the web for other users in the community to try.  They don't
have
> to worry if I am a malicious programmer (or even just a bad one); they
trust the
> compile-time sandbox.

The best way to do that is not so much with D, but describe a DLL interface (or use COM to describe an interface), and let users write COM objects to implement their AI engines.


January 27, 2002
"Walter" <walter@digitalmars.com> wrote in message news:a309lk$1i6u$1@digitaldaemon.com...
>
> "Russ Lewis" <russ@deming-os.org> wrote in message news:3B829F9C.6CF8F3D9@deming-os.org...
> > I think that both of you (Johan and Richard) are missing what I mean. I'm an avid game player.  I want to be able to develop AIs for the games
I
> play,
> > but even the most extensible ones rarely have more than text files where
I
> can
> > tweak parameters.  I want to be able to write a D module that implements
a
> > certain AI API, then dynamically link it into the game.  When I like it,
I
> post
> > the source on the web for other users in the community to try.  They
don't
> have
> > to worry if I am a malicious programmer (or even just a bad one); they
> trust the
> > compile-time sandbox.
>
> The best way to do that is not so much with D, but describe a DLL
interface
> (or use COM to describe an interface), and let users write COM objects to
> implement their AI engines.
>

As I see it, there is no way to system loadable module that is safe. unless
the OS allows an application to determine the amount of the OS API that is
exposed to the module.
It's unsafe(in the case of a dll) because once you call LoadLibrary, that
dll code has access to the underlying OS. COM I believe suffers that same
problem.

Get Bochs, hack the source and run your AI in its own virtual PC!

Mike.


April 09, 2015
Hello, I just stumbled on this thread after searching for an option to do just what you describe; I'm writing a game-like application and was thinking about using D to JIT-compile untrusted source before executing it (making only calls to functions I expose.) I was wondering, have you found any suitable solutions since then ?

Thanks
Chris

as On Tuesday, 21 August 2001 at 17:50:57 UTC, Russ Lewis wrote:
> I think that both of you (Johan and Richard) are missing what I mean.
>
> I fully understand that D cannot create a *runtime* sandbox without implementing
> a Virtual Machine, and even then it's iffy.  What I'm suggesting is a
> *compile-time* sandbox.  (see responses below)
>
> Johan Bryssling wrote:
>
>> Thats a lie.. It doesnt, because you can still link to C-libraries ,
>> granting you total access to the operative system.
>
> Remember, my original post suggested that you limit which modules you can link
> to.  This would certainly include C libraries.  The D standard library would
> include a subset of modules and C libraries which only allowed sandbox-safe
> routines.  Anything that had even remote impact on the machine (other than just
> using memory and processor resources) would be absolutely denied.  Similarly,
> there would be *no asm* so the programmer can't implement his own system calls.
>
>> The virtual machine only gives you a protection against write/read errors in
>> memory. You are talking about the virutal machine like it solves the most of
>> the security problems, that is the most dangerous of all, because it
>> doesnt!!!!!.
>
> In my opinion, the VM (if Java was limited to it) *would* solve all problems.
> The real problem you're describing is not that the VM doesn't work, but that the
> VM has hooks that allow you to get outside of it.  A D compile-time sandbox
> would not have to have these kinds of hooks.
>
>> The security, if any, should be controlled by the programmer and by the
>> operative system and _NOT_ by a sandbox. How well the security are depends
>> how good the programmer are and how many options the operative system gives
>> you. (Linux gives you _TONS_ of options)
>>
>> The best security of all is to hire a very good thrustworthy programmer and
>> _NOT_ preventing the programmer doing "dangerous" stuff by a sandbox. It
>> should not depend on a language or a virtual machine!!!!!!!!!!!!!!!!!
>
> True, for commercial apps.
>
> What I'm envisioning is a situation where people can freely and safely trade
> simple plug-in applications, provided that they don't mind the overhead of
> running them in the compile-time sandbox.
>
> I'm an avid game player.  I want to be able to develop AIs for the games I play,
> but even the most extensible ones rarely have more than text files where I can
> tweak parameters.  I want to be able to write a D module that implements a
> certain AI API, then dynamically link it into the game.  When I like it, I post
> the source on the web for other users in the community to try.  They don't have
> to worry if I am a malicious programmer (or even just a bad one); they trust the
> compile-time sandbox.

April 11, 2015
On Thursday, 9 April 2015 at 01:51:48 UTC, Chris wrote:
> Hello, I just stumbled on this thread after searching for an option to do just what you describe; I'm writing a game-like application and was thinking about using D to JIT-compile untrusted source before executing it (making only calls to functions I expose.) I was wondering, have you found any suitable solutions since then ?

If you compile with -safe option, I suppose the compiler will reject unsafe operations in source.
1 2
Next ›   Last »