[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-general
Subject:    future JDK features: root jail
From:       Bernhard Fastenrath <bfastenrath () mac ! com>
Date:       2004-10-25 19:00:09
Message-ID: 417D4D39.2010207 () mac ! com
[Download RAW message or body]


A root jail mechanism, maybe related to the isolate JSR would be handy.
( http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=170 )

The root jail could allow to chroot(2) an isolate and/or run the I/O of
native subprocesses through a Java  SecurityManager, using a user mode
filesystem mechanism (such as fuse 
<http://freshmeat.net/projects/fuse/>, lufs 
<http://lufs.sourceforge.net/lufs/>, virtualfs 
<http://www.solucorp.qc.ca/virtualfs/>, podfuk 
<http://freshmeat.net/projects/podfuk/>, plasticfs 
<http://freshmeat.net/projects/plasticfs/> or
the Hurd translator system: 
http://www.debian.org/ports/hurd/hurd-doc-translator)

If this mechanism was implemented an open(2) kernel call made by the 
native binary
would be interceptable by the SecurityManager in the Java VM.
Read/write calls to native file would be interceptable by the 
SecurityManager and
resource usage of a native binary could be monitored by the SecurityManager.

To fully exploit a mechanism like that if would be useful to allow the 
Java virtual machine
to implement its own virtual mount points and make these mount points 
visible to the
native binary: The virtual machine would be able to present a 
java.nio.channels.Pipe 
<http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/Pipe.html>
or a java.nio.ByteBuffer 
<http://java.sun.com/j2se/1.4.2/docs/api/java/nio/ByteBuffer.html> as a 
node/file in the filesystem of the jailed native binary.

The main problem seems to be NT here. Maybe an additional driver in the 
filesystem
stack could enable NT to support this feature? A chroot driver would 
have to distinguish
processes that are chroot()ed and reject access by chroot()ed processes 
to files outside
their jail. The same driver would allow to intercept open() calls and 
optionally
read/write calls.

A different approach could  be to modify the access rights of the Isolate
and restrict access to a filesystem which is tightly integrated with the VM
itself. NT supports fine-grained access control, so it might be possible to
just deny all file I/O except for the virtual filesystem presented by 
the VM.

-- 
www.citizens-initiative.org <http://www.citizens-initiative.org/>


[prev in list] [next in list] [prev in thread] [next in thread]