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?

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

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.

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

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

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

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

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.

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

> 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