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: <456C88DC.8080009@apache.org>
Date: Tue, 28 Nov 2006 11:07:08 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Java routine security Was Re: plugging more security holes in Derby
References: <455DF530.1060004@sun.com> <456B8353.7030806@apache.org>
 <456C4AE9.2030607@sun.com>
In-Reply-To: <456C4AE9.2030607@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:

>>> - Create (in that Database) Java Plugins (currently 
>>> Functions/Procedures, but someday Aggregates and VTIs) 
>>
>> Can you explain what this means, what security issue are you trying to 
>> address?
> I'm concerned about being able to exploit security holes in code not 
> supplied by Derby or the application. For instance, security holes in 
> the jdk classes or in other applications hosted on the same vm.

This is actually due to an extension to the SQL standard (part 13) that 
Derby and other databases provide. The ability to have the EXTERNAL NAME 
for a Java routine to be a method in a class without specifying an 
installed jar file name. The security model provided by SQL part 13 does 
provide security by only allowing routines to resolve to a specific 
installed jar file and providing the USAGE privilege on installed jar files.

Derby follows a different path, basically adding an installed jar file 
to derby.database.classpath implicitly grants USAGE on that jar to 
PUBLIC. The ability to perform this implicit grant is, as you say, 
itself under GRANT/REVOKE because one must have EXECUTE permission on 
the procedure to set the database property. Then in addition the class 
in external name in Derby need not come from a jar file, but can be 
resolved from the vm's classpath.

So one part of the solution would be to enhance Derby to support 
installed jar names in EXTERNAL NAME and to implement the USAGE 
privilege, following the SQL standard (part 13).

Then to address the resolution of routines that do not specify an 
installed jar name in EXTERNAL NAME Derby could change from an implictly 
adding the current classpath to the database classpath to a model where 
it must explictily be added. Maybe fixed tokens like:

   JRE        - routines can resolve to any classes that start with 
java. and javax.
   CLASSPATH  - routines can resolve to any classes that are on the vm's 
classpath

E.g.

derby.database.classpath=<unset>
   - No resolution of any routines that do not specify a jar file.

derby.database.classpath=SALES.SALES_FORCAST
   - Only resolve methods from SALES.SALES_FORCAST


derby.database.classpath=JRE:SALES.SALES_FORCAST
   - Only resolve methods from the JRE's java. and javax. classes  and 
classes in SALES.SALES_FORCAST

derby.database.classpath=CLASSPATH:SALES.SALES_FORCAST
   - Only resolve methods from the current classpath, excluding java. 
and javax classes, and those from  SALES.SALES_FORCAST

derby.database.classpath=JRE:CLASSPATH:SALES.SALES_FORCAST
   - Resolve methods as 10.2.


Dan.