db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: what is the right way to fix the import/export security issues (DERBY-2436, DERBY-2437)?
Date Mon, 09 Jul 2007 21:24:47 GMT
Mike Matrigali wrote:
> 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.
>>
5) Martin is adding system privileges (DERBY-2109) as part of 10.4. He 
has already checked in a DatabasePermission class. It should be possible 
to define new kinds of DatabasePermissions which restrict 
import/export/backup/restore to specific subdirectories. So, for 
instance, the customer could add the following permission to the server 
policy file. This permission would prevent Mike from exporting anywhere 
outside his home directory tree:


    grant principal org.apache.derby.authentication.DatabasePrincipal 
"mikem@mikesDB"
    {
      permission org.apache.derby.security.DatabasePermission 
"directory:/usr/home/mikem/-" "export";
    };

Regards,
-Rick



Mime
View raw message