Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <4692A55A.9080406@apache.org>
Date: Mon, 09 Jul 2007 14:15:06 -0700
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: what is the right way to fix the import/export security issues
 (DERBY-2436, DERBY-2437)?
References: <46929F54.1060500@sbcglobal.net>
In-Reply-To: <46929F54.1060500@sbcglobal.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mike Matrigali wrote:
> I am hoping to get a discussion going on how the right way to fix these
> issues.  As I understand it the ability to read/write files is currently
> inherited from derby.jar where the import/export system procedures
> currently reside.  The problem is that this means the they can be used
> to bypass the normal database level read/write access to derby system
> files: property files, database files, log files, temp files.  As dan
> has pointed out I believe the current policy files may allow in one
> database but access files in a completely different database so the
> scope of the files is larger than just the current database.
> 
> I don't know much about security manager possibilities so maybe someone
> who knows can point the way.
> 
> Some approaches:
> 1) try to code access privileges in the routines themselves, that is 
> separate from java security manager.  Basically
>    disallow access to derby files by adding code logic to determine if 
> the files being read/written are derby files.  This is not too hard to 
> do if you
>    only want to disallow under the current database subtree, but gets
>    harder under any derby subtree.
>    So I think this approach  would check for files named:
>    derby.properties
>    system.properties
>    log/log*.dat
>    log/log.ctrl
>    log/logmirror.ctrl
>    seg0/*.dat
> 
>    I think temporary files also, and I think they can be anywhere.

I like the above approach, simple but likely covers most of situations. 
The list would need to include jar/*.jar. I also think you mean 
service.properties and not system.properties.


A "right" Java fix might be to introduce new Derby permissions for 
import and export. Then derby.jar would need to be granted those 
permissions in order to import/export. The permissions could use 
java.io.FilePermission (write for Export, read for Import).

Dan.