db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Derby secure by default
Date Mon, 19 Sep 2011 21:43:30 GMT
Rick Hillegas wrote:

> I'm also concerned about the embedded database on a USB stick. I could 
> argue that it is more vulnerable than the server-side database locked up 
> in a machine room.

Derby has one answer to this issue and that is encrypted databases.  I 
don't think anything other than that is secure.  Because if you lose 
ownership of the files anyone can use a version of the open source 
software to look at the data no matter what you do with authentication 
or authorization.  I sort of doubt even file permissions would help
if someone has physical control of the device and can mount it anywhere.

Having said that, I don't want to also enable encryption by default for
embedded derby.  It is unnecessary for many applications and imposes
performance degredation and application complexity.

Historically Derby was never meant to be secure.  It was designed to
be embedded and for owning applications to handle security.  Early on
the issue of losing ownership of the files was considered and so 
encrytion was added.  Eventually client/server was added and even later
sql authorization, but it was not expected to be used in general for
embedded applications.

>> While many possibly get in the way for many zero-admin
>> embedded applications.
> I'm imagining that this change may be fairly unobtrusive. For an 
> embedded database which has only one user (the dbo), the big change is 
> that the dbo has to specify a username and password. There won't be any 
> need to GRANT access to other users so (2) won't be noticed. Items (3) 
> and (4) won't burden most applications. (5) and (6) are only issues for 
> client/server usage.

In many cases I don't think this is true.   I know users I work with 
currently run an embedded derby application as a number of different 
users and their current application does not use authentication or 
authorization.  As with other files used by the application they manage
access to db files as appropriate for their application.

>>   Since we have one codeline for the most part
>> for both it is hard to have one default.
> I agree that a common default would be best. It will make it easier to 
> reason about Derby's behavior and simplify our user guides.
> Thanks,
> -Rick
>> Rick Hillegas wrote:
>>> 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