This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Restricting system access
- From: Michael Koch <konqueror at gmx dot de>
- To: Thomas Hallgren <thhal at mailblocks dot com>
- Cc: java at gcc dot gnu dot org
- Date: Fri, 25 Feb 2005 21:27:37 +0100
- Subject: Re: Restricting system access
- References: <cvll82$vs1$1@sea.gmane.org>
On Thu, Feb 24, 2005 at 11:46:07PM +0100, Thomas Hallgren wrote:
> My project aims to provide Java to a database backend. The functions that execute within that backend must be restricted from access to external resources
> (such as the file system). Using a standard JVM, I accomplish this by installing a SecurityManager.
>
> The present gcj (I'm running from CVS head) requires "execute on <<ALL FILES>>" by default and I've heard that work on gcj security has just commenced.
>
> I would like to know when you think that the GCJ security model will be mature enough to allow me to create a system where I can prevent virtually all file
> access. As a comparison, using a standard JVM I restrict all FilePermissions except reads in "java.home". I'm not asking for exact dates. I'm more interested
> in your priorities concerning this and a very rough estimate.
I would say GCC 4.1 perhaps. But I don't give a garantee. I started to
write testcases for all kind of security features we need to implement.
Most code is there, just not really tested if it works at all.
Then we need to do a full security audit of classpath/libgcj.
What currently concerns me is that need for "execute on <<ALL FILES>>".
This is needed to execute the external apps addr2line and c++filt to
make stack traces possible at all. I hope this will be gone and windows
changes to DWARF2 and we can use an internal stack unwinder.
Michael