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,


 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

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

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

 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

 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

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

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

 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,


 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

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

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

 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

 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

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

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

 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

 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

 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*

 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"


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

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


 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

 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

 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

 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

 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

 but even the most extensible ones rarely have more than text files where I

 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

 the source on the web for other users in the community to try.  They don't

 to worry if I am a malicious programmer (or even just a bad one); they

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

 but even the most extensible ones rarely have more than text files where I

 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

 the source on the web for other users in the community to try.  They don't

 to worry if I am a malicious programmer (or even just a bad one); they

 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


 play,
 but even the most extensible ones rarely have more than text files where


 can
 tweak parameters.  I want to be able to write a D module that implements


 certain AI API, then dynamically link it into the game.  When I like it,


 post
 the source on the web for other users in the community to try.  They


 have
 to worry if I am a malicious programmer (or even just a bad one); they

 compile-time sandbox.

The best way to do that is not so much with D, but describe a DLL

 (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