db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: making Derby secure by default
Date Fri, 16 Sep 2011 18:55:16 GMT
Thanks, Kathey. Some comments inline...

On 9/16/11 9:06 AM, Kathey Marsden wrote:
> On 9/16/2011 5:59 AM, Rick Hillegas wrote:
>> I believe the benefits of a secure-by-default product are important 
>> enough to justify a backwardly incompatible release and therefore to 
>> bump the major release id from 10 to 11. I believe that Derby's 
>> current security story is unsustainable.
> I believe an ultimate switch and bump to 11 might be doable with the 
> global property to revert to to the prior behavior but I don't  
> entirely understand what the new default will require users to do.  
> I'd like to understand that clearly 
More discussion is required, but here are my initial thoughts for how 
Derby would behave when secureByDefault=true:

The following defenses would be in place in both embedded and 
client/server scenarios:

E1) We would supply a default authentication scheme for use when no 
other scheme is specified. The details of this can be discussed further 
on DERBY-866.

E2) Authentication and authorization would be turned on. If using the 
default authentication scheme, we would store the credentials used to 
create the database; the dbo would be responsible for creating 
additional users.

E3) We would use the tighter file permissions introduced by DERBY-5363.

E4) We would enforce the complete SQL security model for Java routines 
(see DERBY-2206/DERBY-2250/DERBY-2253/DERBY-2252).

E5) The user name PUBLIC would not be allowed.

I don't know what to do about database encryption. For performance 
reasons, we might want to leave it off. Alternatively, we might consider 
default encryption of new databases using a salted version of the DBO's 

The following additional defenses would be in place in client/server 

CS1) The VM owner would have to specify credentials in order to boot the 

CS2) Those credentials would be required in order to shutdown the 
server, shutdown the engine, turn server-side tracing on/off, and in 
general use any of the public functions of NetworkServerControl/NetServlet.

CS3) SSL/TLS would be turned on. Unless overridden, certificate/key 
stores would be expected/created at some default location.

CS4) Some mechanism would control create/restore database powers across 
the network. Discussion needed.

> and have the switch with the reversed default in place for a while for 
> users to work with before we flip the switch on the default and bump 
> the major version. I think it is really important that we are sure 
> that the needed user actions with the option on are well documented 
> and proven in the field before the default is changed.
>> If the whole community can't move to a secure-by-default product, I 
>> am worried that Derby development may fork. Those of us who are 
>> interested in a secure-by-default configuration will put our effort 
>> behind that profile and those who are interested in the old 
>> configuration will focus on the current profile. It may be possible 
>> to limit the fork to personal environments and automated tests, but I 
>> confess, I don't understand how this would play out. Before launching 
>> into that discussion, I would like to ask if the community could 
>> support a secure-by-default 11.0 trunk sometime after 10.9 in the 
>> interests of avoiding a development fork.
> I certainly hope a fork won't be necessary. Worst case there could be 
> an alternate build with the default switched if some people what to 
> distribute the jars with the option flipped if some are more eager to 
> do so.
We should be able to control this with a build-time switch. If we 
released both versions, then we would want to track the difference in 
JIRA somehow.

> Kathey

View raw message