db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <dag.wan...@oracle.com>
Subject Re: Derby secure by default
Date Tue, 20 Sep 2011 22:37:50 GMT
On 9/20/2011 12:20 AM, Mike Matrigali wrote:
> I think that new features that rick is proposing are valuable to some
> set of Derby users, and welcome their inclusion in Derby.  Having one
> flag to enable a set of secure oriented features also seems reasonable
> as long as users can still pick and choose if they don't want the 
> complete set.  I don't think
> they should be made the default in the current release or a future 
> release.
> I believe zero admin upgrade/backward compatibility has been a great 
> feature for Derby so far and we should do whatever we can to not break 
> it going forward.  It seems like applications that need this feature set
> can set the appropriate flag going forward and then do the work to 
> properly configure authentication and authorization, ssl encryption 
> passwords, and other server administration.  Since there is extra work
> necessary to use these features it seems reasonable to put to work on
> these applications to set the flag rather than put the work on the 
> zero-admin applications that do not need these features.
> By default Derby should be zero admin and thus default to not requiring
> this extra administration.

I agree that there is no "secure-by-default" in general, a really secure 
solution needs careful planning and a good understanding of the issues 
and the technology being used. However, that is not necessarily a good 
reason to "leave all doors open" if the user takes no special action to 
close them.
If the database is protected by application level security (as often is 
the case for embedded Derby deployments), this is less of an issue.
I would be OK with keeping the current behavior the default for embedded 

Again, I am less convinced by the argument in a client/server 
deployment: I believe the current behavior there is unwise. I believe it 
would be acceptable/good
to close the "open doors" in a major release upgrade (11.0) - with a 
goal to a keeping the administration to a minimum (minimal admin is nice 
if you want a secure detabase, too..), both for secure deployments [1] 
and not ("turn one knob to get rid of it").

[1] Not sure what the minimums is, possibly creating at least one user, 
generating/installing SSL certs?

>> ------------------------------------------------------------------------
>> *From: *"Rick Hillegas" <rick.hillegas@oracle.com>
>> *To: *"Derby Discussion" <derby-user@db.apache.org>
>> *Sent: *Monday, September 19, 2011 12:39:07 PM
>> *Subject: *Derby secure by default
>> The Derby developers are considering introducing a single master
>> security property. Turning this property on will enable most Derby
>> security mechanisms:
>> 1) Authentication - Will be on, requiring username/password credentials
>> at connection time. Derby will supply a default authentication 
>> mechanism.
>> 2) SQL authorization - Will be on, hiding a user's data from other
>> people. In addition, Derby will support more SQL Standard protections
>> for Java routines.
>> 3) File permissions - Will be tightened as described by DERBY-5363.
>> 4) PUBLIC -This keyword will not be allowed as a user name.
>> 5) SSL/TLS encryption - Will shield client/server traffic.
>> 6) Server administration -  Will require credentials.
>> When the property is off, Derby will behave as it does today:
>> Authentication, authorization, and network encryption will be off, file
>> permissions will inherit defaults from the account which runs the VM,
>> PUBLIC will be a legal user name, and server administration won't need
>> credentials.
>> This new master property will make it easier to configure a more secure
>> application. We want to introduce the property in an upcoming 10.x
>> release, where it will default to being off. That means that it won't
>> cause compatibility problems.
>> Later on, we might change the default for this property so that it would
>> normally be turned on. This would make Derby more secure out of the box
>> at the cost of breaking existing applications. Many applications would
>> need to explicitly turn the property off in order to run as they did
>> previously. Release notes would document this behavioral change and we
>> would bump the major release id from 10 to 11 in order to call attention
>> to the change.
>> We would like your feedback on this trade-off between security out of
>> the box versus disruption. Should this extra security be enabled by 
>> default?
>> Thanks,
>> -Rick

View raw message