Java Secure SandBox (Javass) for openjdk 7 and jdk 6
Since the security manager wasn't cutting it for me. I decided to
create new features to the core of Java. One of the new features is the
ability to lock down the application to a specific path or in unix terms,
chroot the application. Now I know you are probably thinking that a security
manager can do this as well, and the answer is yes and no. While the
security manager can stop people from reading or writing to specific paths.
It cannot change the path or overwrite the path for an application that was
Also it cannot control the storage within a given path or limit the number of
directories, or the number of files that can be created. Javass can give you
control over how much storage an application can use, or how many files
or directories can be created, just by simply changing a property file.
Also I wanted the ability to control the network traffic. Yes I also know
that a security manager can control a socket as far as who connects, but it
does not have the capability to control the speed in which the traffic comes
in or out. Javass lets you control the number of bytes per second coming in
and out. This can be on a socket basis or based on all sockets coming in or
out. Get a security manager to do that!
Javass can run any application with out any fears of what an
application really does. You can even take a malicious program and run it
without any fears. With a configured properties file, no program can hurt
the OS or file system you are using. If a program for arguement sakes needs
to use a file in the directory /etc. Then setup a properties file with a
base path and copy the directory /etc to the 'BasePath/etc', then the
program will use the fake /etc directory and files. If you want to use
the original /etc directory, then add a property called 'AllowedPathX=/etc'.
Javass can still install and use a security manager just like you did
in the past. Javass runs with a security manager if need be. But for most of
us that don't want to write or maintain security managers. Then all you
have to do is edit a property file to use Javass. Below is a full list of
- the class loader works from a base path now
- added IgnoreSizes flag, which ignores any directory and file
reading of sizes. If the user does not require or care about
file and directory sizes, then use this flag.
- fixed some more issues with networking.
- fixed some networking errors with the previous release
- added ipV6 updates
- add new verbose modes for quick debugging.
- added more real world examples.
- add separate settings for each thread now.
- made the file path change only if there needs to be a change
which corrected a few issues with tomcat as well as JBoss.
- Overwrite and lock users to a specific base path (like chroot in unix)
- All temporary files will be created in the base path if
java.io.tmpdir is not overridden.
- You can limit the amount of storage being used for a path or file
- You can make the base path read only or read/write.
- limit the number of files and directories created with in a path.
- allow or deny whether libraries can be loaded from a path.
- allow or deny whether native methods can be used from a path.
- You can have multiple paths to allow users to read or write to with
different limiting storage and or # or files and directories.
- limit the number of threads and thread priority.
- limit the maximum # of windows being created.
- allow or deny hosts and ports being used.
- allow or deny execution of runtime process.
- limit the socket bandwidth traffic both in and out (bytes per
- Allow threads to have different paths, or to lock every new thread
with certain paths.
- Allow users to configure paths using a key
Binary and source code can be downloaded from:
Download files now!
If you want to install the binary then you need linux (x86). If you
want to install the patch and compile the binaries for yourself. Then you need
to acquire the jdk source code from Sun.
for jdk 7 go to:
for jdk 6u3 go to:
Once you have the jdk source code, and you are in the jdk source directory.
Then type in
for openjdk 7
patch -p0 < /path/to/openjdk_7_b47.patch
for jdk 6u3
patch -p0 < /path/to/jdk6u3_Javass.patch
Next you can use the build script that I packaged with this patch, or use your
own. If you do decide to use my build script, then remember to change the
BASESOURCE variable to your openjdk source path, and you might need to change
the PLUGINPATH or ALT_BINARY_PLUGS_PATH. Once you have built the jdk,
then you should have a build directory and inside this build directory
you should see 2 directories:
You could set the PATH to either directory. Next you can try out some of the
examples that I provided (All source code is supplied)
To configure a Javass property file, you can start with one of the
provided examples. The following is a list of supported parameters:
ConfigErrors= Flag - Stop on path errors.
Verbose= Flag - Display some information regarding setup and networking
VerbosePath= Flag - Display every File path used with an application.
(Very detailed, this can be a lot of data, you might need to
redirect the output to a file).
IgnoreSizes= Flag - Used to stop reading a path and all the files and
directories when the path is writable. No checking will
occur for file and directory sizes.
MaxThreads= int - Maximum # of threads allowed
MaxPriority= int - Maximum thread priority allowed for all threads
PathsPerThread= Flag - When set to true each thread will take on at start
all the AllowedFileX, AllowedPathX, and BasePath data. Then
it is up to the users application to change the path data,
using the Thread.setName(""). The name will no change the
if the data passed to setName is in the Javass format.
AllowAllPaths= Flag - If set then all Paths can be added. If not set,
then all paths must be equals to one of the initial paths
from start (AllowedPathX, AllowedFileX, or BasePath).
PathKey= String - A key that is used in conjuction with PathsPerThread
The key is the first parameter when passing path information
to a thread using setName("key,a,path,rw,900k,1,0");
MaxWindows= int - Maximum # of windows that can be created
AllowExecute= Flag - Allow applications to execute system commands
AllowExit= Flag - Allow applications to exit.
AllowNetworking= Flag - Basically allow or deny networking
InputSpeed= int - Maximum speed for input traffic (bytes per second)
LimitAllInput= Flag - All input traffic will be limited to the in speed
OutputSpeed= int - Maximum speed for output traffic (bytes per second)
LimitAllOutput= Flag - All output traffic will be limited to the out speed
DenyAllInHost= Flag - Deny all host traffic in (default deny all in)
DenyAllOutHost= Flag - Deny all host traffic out (default deny all out)
AllowHostIn(X)= String - Allow host:port in (You don't need the port)
AllowHostOut(X)= String - Allow host:port out (You don't need the port)
DenyHostIn(X)= String - Deny host:port in (You don't need the port)
DenyHostOut(X)= String - Deny host:port out (You don't need the port)
AllowedPath(X)= String - By using AllowedPathX, then the application can
use the specified path, with the permissions you setup.
AllowedFile(X)= String - similar to AllowedPath(X).
BasePath= String - The is the lock down directory where all paths that
don't fall under AllowedPathX, will be placed in here.
Note if the BasePath is not defined, then there is no
restrictions on the file system. Another way of looking at
BasePath is to think of it as chroot in unix.
Both AllowedPathX and BasePath use the same parameters on the end. If you want
to create a BasePath that can read and write upto 10 meg, and don't allow
library and native methods to be used would like like:
You can specify the storage space in kilo bytes as well, just use the letter k
at the end of your storage requirements. To allow a directory to be read with
no write privledges, but allow libraries and native methods would look like:
To run and test your settings type in the following:
java -DJavass=/path/to/your.properties -jar yourapplication.jar
I have tested Javass with a number of applications, including tomcat.
One thing should be noted here, and that is when using a BasePath, then you
should be inside the BasePath directory when running your application. Also
if you have links to a path, then you should use an absolute path as well in
your properties file. In other words use another AllowedPathX with the
absolute path, so you should have 2 paths for the one path you are concerned
with. An example would be a path /opt/tomcat which is linked to
/opt/apache-tomcat-6.0.14. So you would have 2 directives in the properties
file. If your application uses temp files, then the files will be created in
BasePath/tmp directory. Only if the BasePath is writable, otherwise temporary
files will not be created. If your application needs temporary files and you
BasePath is not writable, then you could add an AllowedPathX line to /tmp path,
or add an AllowedPathX to the BasePath/tmp with writable permissions.
The rest of which you can try out, and play with yourself. ;-)
With Javass in place, you can run any application without any worries.
As soon as you use a BasePath, then you know the application cannot write or
read to any file. An application can access any file from the tree of
BasePath as well as any defined AllowedFileX or AllowedPathX. So any
application can run in a safe defined user environment. The application
doesn't have to be signed in order to be secure. In fact you can run any
application even if you are not sure what it does.
In the future I was thinking of maybe adapting this to a browsers
plugin. So plain old jars could run. But not only that, an applet or jar
doesn't have to be signed, because with Javass in place, you don't have to
worry about an application getting out of the sand box, and writing or reading
to any file you don't want accessed.
Good luck and have fun! Who knows maybe Sun will put these enhancements in the