db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: what is the right way to fix the import/export security issues (DERBY-2436, DERBY-2437)?
Date Mon, 09 Jul 2007 20:59:33 GMT
Another approach might be to just disallow import/export on files that
are under system home.  This might be a backward compatibility issue.
If compatibility were an overriding issue then we could just do this in
10.3 for blob/clob import/export leaving the possible holes that already
exist in 10.2.

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.
> 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.

View raw message