Application in sandbox

[Tim Tyler]

Hi.

I have an application (in a Jar file) which I don't trust - and would
like to run securely - in a sandbox.

Does anyone know the easiest way?

 

[Andrew Thompson]

I have an application (in a Jar file) which I don't trust - and would
like to run securely - in a sandbox.

Does anyone know the easiest way?

Launch it from an applet. It will inheret the applet sandbox.

HTH

 

[Andrew Thompson]

Launch it from an applet. It will inheret the applet sandbox.

Or, for more finely grained control, ..
<http://groups.google.com/[email protected]>

HTH

 

[Tim Tyler]

Launch it from an applet. It will inheret the applet sandbox.

So: has anyone done this before? Does it work?

One problem I forsee is that any command-line apps requiring input would
all fail.

A more cosmetic problem would be that it (messily) leaves an appletviewer
window hanging around with no content in it. I guess I could live with
that.

Maybe there's an applet which accepts the main method as a parameter -
and then uses reflection to call it? Otherwise you have to recompile
Java code each time you want to do this - not exactly a low-hassle
approach.

Even as it is, it seems you would have to edit HTML files to include the
relevant jar files.

A WebStart approach may work slightly better than an applet-based one -
since the WebStart sandbox is slightly less screwed that the applet
sandbox, and it's *designed* for running applications in. There may
be more config files to edit there, though.

I guess what I /really/ want is something like:

"java -sandbox <permission.file>"

 

[Andrew Thompson]

So: has anyone done this before?

Probably numerous times.
<http://www.physci.org/codes/tame/applet.jsp>
You're looking at an applet that launches the JFrames
of the Tame Swing codes. Another example of the same applet..

Does it work?

Yes. But then, it only takes about 30 lines of code to
test it for yourself. Go on, ..be daring. ;-)

 

[Andrew Thompson]

.

I guess what I /really/ want is something like:

"java -sandbox <permission.file>" ...

In that case look to the other solution. It allows more
finely grained control.

 

[Tim Tyler]

In that case look to the other solution. It allows more
finely grained control.

Yes - the "other solution" has the guts of a usable approach - thanks.

 

[Andrew Thompson]

Yes - the "other solution" has the guts of a usable approach - thanks.

You're welcome.

 

[yunhong min]

test

 

[Jean Lutrin]

Hi.

I have an application (in a Jar file) which I don't trust - and would
like to run securely - in a sandbox.

Does anyone know the easiest way?

Well, I have a similar problem to yours: there's a particular
operating system that I don't trust.



So I run Un*x operating systems (several flavors, on different kind
of hardware).

On my main development machine, wich I sometimes use to test "closed
source" Java programs/plugins, etc. (or even "open source" programes
that I'm not sure have been correctly audited), I simply do the
following:

....jean $ su insecure
Password: *****
....insecure $ java -jar someJarIDontTrust.jar

The "insecure" account has very restrictive rights and hence won't
be able to do much mischief.

It takes 5 seconds. I don't know if this can qualify for the
easiest way (I suppose your not running Un*x though).

It should be possible to do something similar under 2000 / XP no !?

I'm not sure about how you go to use, simultaneously, graphical
applications from different users displayed in the windowing
environment (but I trust a particular company to have
a very limiting EULA regarding what you're allowed to do according
to how much you paid for "server edition" or "professional edition"
or whatever). YMMV, but it should be possible to do at least something
similar to that.

Similarly, I have a account that is prevented to access the net (by
one single elegant stateful firewall rule) to prevent apps I don't
trust to "phone home".

As I already said, I belong to this very small (and not very
vocal) minority that happens to think that Un*x + Java is a
wonderfull setup for a developer (most Java developer use Windows
and most Un*x users have a grip with Java not being true
Open Source Software).

It's, IMHO, safer, faster and way more configurable.

Java 1.4.2 + IntelliJ 4.5.1 (Eclipse 3 on some projects) + Linux
Fedora Core 1.

Uptime in months. I don't remember when was the last time that
a Java app crashed. And all this for free besides IntelliJ Idea (but
Eclipse, xemacs/jdee, etc. could do the job).

See you soon on c.l.j.p.,

Jean

 

[Sudsy]

Jean Lutrin wrote:

As I already said, I belong to this very small (and not very
vocal) minority that happens to think that Un*x + Java is a
wonderfull setup for a developer (most Java developer use Windows
and most Un*x users have a grip with Java not being true
Open Source Software).

<snip>

I do all my Java development on Linux. It's a more appropriate environment
for enterprise applications. I also have DB/2 and Oracle running along with
some other "industrial strength" apps which likely wouldn't play nicely
together on a M$ box. With one production Apache/Tomcat context, two Tomcat
instances for testing and QA, JBoss, etc., I'd be hard-pressed to come up
with such a sweet environment on that proprietary platform...
So I love both Java AND *NIX. I'm sure I'm not alone.

 

[Steve Sobol]

I do all my Java development on Linux. It's a more appropriate environment
for enterprise applications. I also have DB/2 and Oracle running along with
some other "industrial strength" apps which likely wouldn't play nicely
together on a M$ box. With one production Apache/Tomcat context, two Tomcat
instances for testing and QA, JBoss, etc., I'd be hard-pressed to come up
with such a sweet environment on that proprietary platform...
So I love both Java AND *NIX. I'm sure I'm not alone.

I use Eclipse on a Windwoes box, but that's just because there's a lot of stuff
I need to use (or prefer to use) that *isn't* available on Linux. Eclipse
should run just fine on Linux or any other Unixish system that has a port of
GTK. I do run my app server on Linux, though. (Moving it over to Solaris, but
that's just because I have a SPARCstation available that isn't being used for
anything right now and my Red Hat box is running a buttload of services. Jetty
runs just fine on Linux.)

 

[Tim Tyler]

As I already said, I belong to this very small (and not very
vocal) minority that happens to think that Un*x + Java is a
wonderfull setup for a developer (most Java developer use Windows
and most Un*x users have a grip with Java not being true
Open Source Software).

IMO, they have a good point.

The fact that Java is proprietary, commercial software is its
biggest weakness - in my book.

Nobody in their right mind wants to build their house on land
owned by someone else.

 

[Thomas Weidenfeller]

As I already said, I belong to this very small (and not very
vocal) minority that happens to think that Un*x + Java is a
wonderfull setup for a developer (most Java developer use Windows
and most Un*x users have a grip with Java not being true
Open Source Software).

You are mixing Linux programmers/FOSS religion and Unix programmers.
From my observation, the grips of Unix programmers (not Linux
programmers) with Java are often just the typical Java problems (slow
startup, lack of desktop integration, etc.).

Some, like slow VM ,startup are particular annoying on Unix, when e.g.
writing tools, because people are used to small, quick starting tools
like grep, awk, sed, etc. And it is just not acceptable having to wait a
few seconds for a simple text filter to start up.

In addition, Java is not very well suited for system programming in
general, but a lot of Unix programming is system programming. A lot of
Unix system calls and library functions are only accessible via JNI
code, which makes system programming with Java annoying.

This is not only a problem for system programs, but also for end-user
applications, where you often have to re-invent the wheel. Which is
particular annoying when you know Unix well enough to know that there is
a standard API, but you just can't get access to it from Java in a
straight forward way.

It gets really annoying if you have to communicate in some way with
existing Unix applications, and have no choice over the communication
mechanism. I am just having such a problem. I have to talk via TI-REC
with FDR messages to an existing application. This will definitely
become a C or a C++ application. It is just so much simpler to run the
existing *.x XDR definitions through rpcgen to get C headers and stubs
than trying to get a working Java API for that on (oh, I am sure there
is one, but I don't have the time to search for one, and figure out all
its shortcomings).

I know I will have to pay a price for using C (no standard collections,
memory leaks, dangling pointers, the full show ...), but it still seems
like the smaller risk in the particular case.

/Thomas

 

[Sudsy]

IMO, they have a good point.

The fact that Java is proprietary, commercial software is its
biggest weakness - in my book.

Nobody in their right mind wants to build their house on land
owned by someone else.

Guess what? The government can exercise their right of "eminent domain"
and take your land anyway. So your analogy is either very good or very
bad, depending on your point of view.

 

[Bent C Dalager]

Hi.

I have an application (in a Jar file) which I don't trust - and would
like to run securely - in a sandbox.

Does anyone know the easiest way?

If you just want to run it once to test it, you might change the
java.security file (I think that's the name) to have the default
permissions be the most strict set possible.

I think you just remove most of the lines in the "grant {}" block.

Of course, then _all_ the apps you run will get no permissions, but
for a one-off test changing the file back again afterwards should work


Cheers
Bent D

 

[Steve Sobol]

IMO, they have a good point.

The fact that Java is proprietary, commercial software is its
biggest weakness - in my book.

You're right. We should all use .NET because it's open source.

Come on... yes, technically Java *is* a commercial product, however...
Proprietary? How can you say it's proprietary when the source code is sitting
on the Web downloadable by anyone?

 

[Bent C Dalager]

Come on... yes, technically Java *is* a commercial product, however...
Proprietary? How can you say it's proprietary when the source code is sitting
on the Web downloadable by anyone?

It is proprietary because it is owned by Sun and noone else is allowed
to touch it(*) unless Sun give their permission.

The fact that you can actually _see_ it doesn't change this.

(*) - Well, you might be allowed to touch it if you do so only in the
confines of your own home and don't use the resulting code for
anything beyond personal use but I would consult a lawyer before
trying even that

Cheers
Bent D

 

[John C. Bollinger]

So: has anyone done this before? Does it work?

I have not tried it, but as I understand applets, this will FAIL if the
applet is loaded from the local machine, although it will work if the
applet is loaded from a remote server. As Andrew suggested, you should
test it before relying on it.


John Bollinger
(e-mail address removed)

 

[Tim Tyler]

You're right. We should all use .NET because it's open source.

I made no mention of .NET.

The competitors of Java under slightly more liberal licenses are
things like Python and PHP.

Come on... yes, technically Java *is* a commercial product, however...
Proprietary? How can you say it's proprietary when the source code is sitting
on the Web downloadable by anyone?

Simple: because Java is owned by Sun.

For more details, see:

http://dictionary.reference.com/search?q=proprietary