www.digitalmars.com         C & C++   DMDScript  

D - A Java-style sandbox without a Virtual Machine?

reply Russ Lewis <russ deming-os.org> writes:
One of the *really* nice things about Java was the fact that all code
ran in a sandbox, ensuring that the program could not do various
dangerous things.  This gave users the confidence that they could run
code from a untrusted source and that the Java language model would
protect them from security breaches and virii.  While this has been most
visible for its use on the Web, I think that this model has a lot of
potential for allowing users to create, share, and safely use small
"plug-ins" for their favorite programs.

I've been pondering if D could somehow do something similar.

The first and most obvious problem is that anytime you run binaries
natively on your processor you cannot guarantee such a sandbox.  So
allowing people to download binaries, even if they were compiled with D,
is useless.  But if we allowed people to download D source (or some
pre-processed D symbol file) which they would compile and run on their
own machine, then we could implement features into the compiler and the
libraries to create a sandbox through other means.  My thoughts:

* Implement a subset of the libraries that are safe for sandbox mode.
Thus, they would have basic utility functions but no directory or
network access.
* Disable all asm blocks in sandbox mode, so code can't create its own
system calls.
* Enable "memory tracking" in sandbox mode; the program dynamically
keeps track of all memory allocated with new[] (or implicitly allocated
as stack variables), and all pointers are checked for validity before
being followed.  This option, of course, would be turned off when doing
a normal compile of D code.

From my first cursory look, it seems to me that these 3 features would
create enough of a sandbox.  The code could not access any system
routines except those it got from modules that it imported, and it could
not muck with (or even read) any memory that did not belong to it.

So, two questions:
1) Is this reasonable to implement?
2) Are there other security features to consider?
Aug 20 2001
parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Russ Lewis" <russ deming-os.org> wrote in message
news:3B814A31.4962EB37 deming-os.org...

 One of the *really* nice things about Java was the fact that all code
 ran in a sandbox, ensuring that the program could not do various
 dangerous things.  This gave users the confidence that they could run
 code from a untrusted source and that the Java language model would
 protect them from security breaches and virii.  While this has been most
 visible for its use on the Web, I think that this model has a lot of
 potential for allowing users to create, share, and safely use small
 "plug-ins" for their favorite programs.

 I've been pondering if D could somehow do something similar.


The machine-code equivalent to a "sandbox" is a "process."  Time-sharing
multi-user operating systems have been guarding the machine and other
applications from errant (and malevolent) programs for decades.

I believe this is not a language issue.  You can "sandbox" machine code, but
the OS is the entity that must do it.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 20 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Richard Krehbiel wrote:


 The machine-code equivalent to a "sandbox" is a "process."  Time-sharing
 multi-user operating systems have been guarding the machine and other
 applications from errant (and malevolent) programs for decades.

 I believe this is not a language issue.  You can "sandbox" machine code, but
 the OS is the entity that must do it.


True and not true.  Consider some typical OS'es:

* Windows: no protection at all, unless you're running NT/2000.  Muck with
memory all you want.  Even in NT and 2000 you have practically unlimited access
to the file system and sockets.  Therefore, code you download could include a
Trojan that copies your data out through the network to somebody else or worse
yet delete it altogether.  By putting some D programs in the sandbox you
described, you prevent that.
* Unix: similar to NT/2000.  Includes memory protection, but no file system
protection (other than permissions) and no network protection (other than
preventing you from opening server ports < 1024).

Thus, you can't expect any of the major operating systems to be able to give you
a safe sandbox where the program can't see files, can't connect to the network,
or do other potentially compromising things.  I think that with the sandbox I
described you could.
Aug 20 2001
next sibling parent "Richard Krehbiel" <rich kastle.com> writes:
"Russ Lewis" <russ deming-os.org> wrote in message
news:3B816707.5CB011A9 deming-os.org...

 Richard Krehbiel wrote:


 The machine-code equivalent to a "sandbox" is a "process."  Time-sharing
 multi-user operating systems have been guarding the machine and other
 applications from errant (and malevolent) programs for decades.

 I believe this is not a language issue.  You can "sandbox" machine code,




but

 the OS is the entity that must do it.


 True and not true.  Consider some typical OS'es:

 * Windows: no protection at all, unless you're running NT/2000.  Muck with
 memory all you want.  Even in NT and 2000 you have practically unlimited


access

 to the file system and sockets.  Therefore, code you download could


include a

 Trojan that copies your data out through the network to somebody else or


worse

 yet delete it altogether.  By putting some D programs in the sandbox you
 described, you prevent that.
 * Unix: similar to NT/2000.  Includes memory protection, but no file


system

 protection (other than permissions) and no network protection (other than
 preventing you from opening server ports < 1024).

 Thus, you can't expect any of the major operating systems to be able to


give you

 a safe sandbox where the program can't see files, can't connect to the


network,

 or do other potentially compromising things.  I think that with the


sandbox I

 described you could.


Let me put it this way:

If you're not an OS, you can't sandbox machine code.  You Just Can't Do It.

Whether available popular OSes are adequate to the task is irrelevant.
Whether or not it would be a good thing to do is irrelevant.

A machine code program can peek, and jump, anywhere in addressable memory.
So to protect against malicious code, you have to remove things from memory,
hide it with the MMU, get it out of reach.  The only thing that can alter
the MMU mapping is the OS (except in cases where the OS is so unprotected
that the MMU registers are addressable by mere applications - like, I
believe, MacOS).

My point is, sandboxing may be great, but the D language just can't do
anything about it.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 21 2001
prev sibling parent reply "Johan Bryssling" <johan.bryssling micronet.se> writes:
Greetings..

IM suprised that people have not learned from the lesson of the usage of the
Java virtual machine(JVM or sandbox).

We dont need another sandbox "protecting" the operativsystem from
"brainless" usage by a programmer.
What we REALLY need are good programmers, but however we still need options.

I must comment some arguments you have with experience I have from
proffesional development in Java. (hi-tech "high-performance" servers and so
forth).

But if the D -makers could do a compiler that creates byte code and a DVM
(D- Virtual machine) it would be cool as an option, but nothing more!


 By putting some D programs in the sandbox you
 described, you prevent that.


Thats a lie.. It doesnt, because you can still link to C-libraries ,
granting you total access to the operative system.

For example, if you want to increase performance below the logic level
(logic level = e.g enhancing algorithms) , you should use C++ or C or make a
link to library (SO or DLL file for an example) from JAVA (not javascript
;-) )  and execute the code within the library.  Java uses lots of links to
libraries, the most famous example are the OpenGL library that makes it
possible for you to draw 3d graphics in applets.

The Virtual machine is an excellent idea on the paper, but if you are a good
programmer you may actually make a virus in java, destroying everything in
your path (by linking to a C/C++-library). Suddenly JVM has become a good
place to "hide" code. How many suspects a tiny program within a JVM if
everyone thinks it secure???!

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!!!!!.

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!!!!!!!!!!!!!!!!!

regards

Johan Bryssling, Software engineer, Micronet





"Russ Lewis" <russ deming-os.org> wrote in message
news:3B816707.5CB011A9 deming-os.org...

 Richard Krehbiel wrote:


 The machine-code equivalent to a "sandbox" is a "process."  Time-sharing
 multi-user operating systems have been guarding the machine and other
 applications from errant (and malevolent) programs for decades.

 I believe this is not a language issue.  You can "sandbox" machine code,




but

 the OS is the entity that must do it.


 True and not true.  Consider some typical OS'es:

 * Windows: no protection at all, unless you're running NT/2000.  Muck with
 memory all you want.  Even in NT and 2000 you have practically unlimited


access

 to the file system and sockets.  Therefore, code you download could


include a

 Trojan that copies your data out through the network to somebody else or


worse

 yet delete it altogether.  By putting some D programs in the sandbox you
 described, you prevent that.
 * Unix: similar to NT/2000.  Includes memory protection, but no file


system

 protection (other than permissions) and no network protection (other than
 preventing you from opening server ports < 1024).

 Thus, you can't expect any of the major operating systems to be able to


give you

 a safe sandbox where the program can't see files, can't connect to the


network,

 or do other potentially compromising things.  I think that with the


sandbox I

 described you could.
Aug 21 2001
next sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Johan Bryssling" <johan.bryssling micronet.se> wrote in message
news:9lthht$245m$1 digitaldaemon.com...

 Greetings..

 IM suprised that people have not learned from the lesson of the usage of


the

 Java virtual machine(JVM or sandbox).

 We dont need another sandbox "protecting" the operativsystem from
 "brainless" usage by a programmer.


The purpose of the sandbox is not protection from "brainless" programmers;
the purpose of the Java sandbox is protection from *malevolent* programmers,
evil programmers, programmers whose goal is to steal your data, your
passwords, your credit card information, and wreak as much physical damage
upon your machine as they can.


 I must comment some arguments you have with experience I have from
 proffesional development in Java. (hi-tech "high-performance" servers and


so

 forth).


Think about what it would mean if anyone on the web could install whatever
code they wanted onto your servers.  That'll get you into the right mindset
about the Java sandbox.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 21 2001
parent reply "Johan Bryssling" <johan.bryssling micronet.se> writes:
Hi!!


 The purpose of the sandbox is not protection from "brainless" programmers;



 the purpose of the Java sandbox is protection from *malevolent*


programmers,


 evil programmers, programmers whose goal is to steal your data, your



 passwords, your credit card information, and wreak as much physical damage



 upon your machine as they can.


Yes, I know what you meant but it exists evil programmers and it always
will. You will fool yourself if you think you can "build them out" by
creating a new language or "sandbox". Because you cant. But you can make it
a lot harder for them.


 Think about what it would mean if anyone on the web could install whatever



 code they wanted onto your servers. That'll get you into the right mindset



 about the Java sandbox.


Yes, but what kind of moron would write such a server? You would be asking
for trouble. ;-)

(Good example: Microsoft IIS(internet information server)
security-flaw-server! It allowed uploaded code to be executed.. *sigh*)

(More examples: Webservers installed as root and allowing CGI-programs to
execute as root, the cgi program may now execute operative system commands
like adduser, rm.... as it pleases.  Cure: install the server as a user(e.g
webserver) with limited execution rights.)

So if you must set up a Web server with CGI support and so forth you must
know exactly what you are doing. Because the users WILL use CGI and SOME of
those users WILL use the service in a evil way!

Personally I will never write a server that allow execution of uploaded
code, not even with a "sandbox"!!!!!!!!!!(security suicide)

If you still can make links to other C/C++-libraries from a sandbox you
still dont have any security!

So it's my responsability to make my servers secure as it can get and tuning
the operating system it runs on. Both windows (especially windows) and Linux
have security holes, often we arent aware of it. If we have a "hole" in the
operating systems, the sandbox still cannot protect our server-application.

I dont thrust the operative systems and that makes me aware of the risks. I
might give the sandbox a plus but I would never thrust it. Besides that I
like the idea, but we must be realistic.

The highest possible security is achived thru knowledge and tuning of the
operativesystem and DONT allow the server application to execute uploaded
code! (But if you must write a server that wants to execute code.. I have
several ideas ... but I will not mention it here.)

Regards

Johan Bryssling, Software engineer, Micronet
Aug 21 2001
parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Johan Bryssling" <johan.bryssling micronet.se> wrote in message
news:9ltvs9$2c3l$1 digitaldaemon.com...

 Hi!!


 The purpose of the sandbox is not protection from "brainless"




programmers;

 the purpose of the Java sandbox is protection from *malevolent*


 programmers,


 evil programmers, programmers whose goal is to steal your data, your
 passwords, your credit card information, and wreak as much physical




damage

 upon your machine as they can.


 Yes, I know what you meant but it exists evil programmers and it always
 will. You will fool yourself if you think you can "build them out" by
 creating a new language or "sandbox". Because you cant.


But that's just what the Java language promises.

The goal of Java (and Javascript and VBScript) is to (pardon me for using
MS-like terms) "enrich" a surfer's web "experience" by offering the web page
designer a high-bandwidth link from their code to the user's screen - and
that means downloaded code.  Sun has promised that the Java sandbox protects
the client's resources and data from malicious Java code.  And it seems to
be (mostly) true; when was the last time you read a CNN report on a nasty
Java exploit?

Yes, "traditional wisdom" rules out code downloaded from untrusted sources.
And of course, you've disabled Java and JavaScript in your browser, right?

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 21 2001
parent "Johan Bryssling" <johan.bryssling micronet.se> writes:
 But that's just what the Java language promises.


The only thing that java promieses that it takes shorter time to develop
certain types of programs. There are three types of programs you may
develop: Java applets ( windows shown in browsers)  , Java applications
(like word and stuff but made in java... ) and Java Script (that is not
"real" java. Parsed by the browser, and dont uses a virtual machine)


 The goal of Java (and Javascript and VBScript) is to (pardon me for using
 MS-like terms) "enrich" a surfer's web "experience" by offering the web


page

 designer a high-bandwidth link from their code to the user's screen - and
 that means downloaded code.


Yes, but I was talking about _UPLOADING_ code to the server and
server-safety, not _DOWNLOADING_ and clients. VBScript and JavaScript (does
not run in a virtual machine) are not languages like "real" java or C++.
Again, its up to the programmer of the browser  (that parses the request),
how to make the "enriched experience" safe. Scripts are powerful because the
programmer of the browser(or whatever) let you, not the language!


 Sun has promised that the Java sandbox protects
 the client's resources and data from malicious Java code.  And it seems to
 be (mostly) true; when was the last time you read a CNN report on a nasty
 Java exploit?


No, because Java is a programming language, not a program or an operative
system. When did you hear about a nasty C++ exploit? Programs (applications)
made in Java are not safier than the surrounding operative system are. I was
trying to tell  you that it is the programmers responsabililty to make it
safe , not SUN or the language in itself. The java virtual machine are just
another program in the operativsystem that may be manipulated.

BTW: How many java applications(like word, excel, outlook) do you really
use?
I guess it's around zero. So how many programs may be "infected"/"evil" and
how many Java program exploits do you hear if you/common people dont use
any?


 Yes, "traditional wisdom" rules out code downloaded from untrusted


sources.

 And of course, you've disabled Java and JavaScript in your browser, right?


I was not talking about client/user security, I was talking about writing
secure java/C++/C programs. The most programmers lack the knowledge how the
operative system works and how to create safe programs.

You cannot access the low-level operative system functions with JavaScript
(unless the browser permitts it with "special" commands), but you can do it
with Java-applications and no I have not disabled java in the browser.. ;-)

If you dont know what I mean with "special" commands, look up the Java
Script specification for Netscape and Internet Explorer and compare...

Java applets("java-windows" shown i browsers) have more restrictions that
makes it fairly safe.
These restrictions are:
*An applet cannot have any access to files on the local computer.
*An applet cannot invoke any other program on the local computer
*An applet cannot comminicate with any computer other than the computer from
wich the HTML page conatining  the applet was downloaded.

These restrictions have nothing ,what so ever, to do with the Java virtual
machine.

BTW: I have used lots of SUN products, not because I want , but because the
company wants.  I DO NOT thrust SUN to 100% , (because JAVA is still under
development and it exist bugs everywhere in the different virtual machines).
However I thrust myself and my own experience and uses it to make "secure
and safe" software that survives in an "secure and safe" tuned enviroment.

If you only thrust the language to solve all you security problems, it's
your mistake.

Regards

Johan Bryssling, Software engineer, Micronet
Aug 22 2001
prev sibling parent reply Russ Lewis <russ deming-os.org> writes:
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.
Aug 21 2001
next sibling parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
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.
Aug 22 2001
parent reply Russ Lewis <russ deming-os.org> writes:
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.
Aug 22 2001
parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
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.
Aug 22 2001
parent Russ Lewis <russ deming-os.org> writes:
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.
Aug 22 2001
prev sibling next sibling parent "Richard Krehbiel" <rich kastle.com> writes:
"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.
Aug 23 2001
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 26 2002
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"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.
Jan 27 2002
prev sibling parent reply "Chris" <breathe67 gmail.com> writes:
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.
Apr 08 2015
parent "Kagamin" <spam here.lot> writes:
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.
Apr 11 2015