db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject what is the right way to fix the import/export security issues (DERBY-2436, DERBY-2437)?
Date Mon, 09 Jul 2007 20:49:24 GMT
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.


2) Is it possible to temporarily give up a set of granted security 
privileges in a class and get them again on the way out?  Basically
import only wants the write derby access privilege and export only
wants the read derby access privilege.

3) Could the routines be moved into a separate jar that would get a 
different set of security manager privileges?

4) we could get rid of the current interfaces all together and change
to require streams rather than files for the user files.  This may be
a lot slower and does raise backward compatibility issues.  The point
of import/export is to allow easy/fast bulk load/unload, so doesn't 
really solve the issue.

Mime
View raw message