db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Derby secure by default
Date Tue, 20 Sep 2011 15:09:44 GMT
On 9/19/11 5:28 PM, Kathey Marsden wrote:
> On 9/19/2011 1:20 PM, José Ventura wrote:
>>
>> I'm not sure whether making the default value "on" will actually 
>> improve security as a whole. If a developer hasn't given thought to 
>> security, there are plenty of other pitfalls that may compromise an 
>> application (e.g. "where should I store the (previously unneeded yet 
>> now required) username and password?").
>>
>> On the other hand, if s/he did in fact think about security, then 
>> odds are that are a simple, concise documentation will point him/her 
>> to happily turn on the switch with minimum nuisance, and proceed to 
>> secure the rest of the application.
>>
> I think this is a very good point. The claim of   "secure by default" 
> is a very strong claim  and may give a false sense of overall 
> security. Some things, like encryption and perhaps stricter security 
> manager settings are not part of the default, but might be an 
> important part of actually securing a particular application.  I agree 
> it is good for the application developer to plan security and for us 
> to make it as easy as possible for them to do so from a Derby 
> perspective.
>
>  Perhaps the conversation of the default is premature.  Perhaps we 
> should first nail down the easy security knob and  understand its 
> behavior and usefulness and then discuss whether it should/could  be 
> the default.
> Kathey
>
>
>
>
Thanks, talking about these details would be useful now.

A) On/off switch - A simple scheme would be a property with two values. 
The property is stored in the database at creation time, as is done with 
derby.connection.requireAuthentication. Once stored in the database, the 
property can't be changed.

    derby.security.basic=true

This enables the initial set of security features which I included in my 
first posting (copied at the end of this message).

    derby.security.basic=false

This is the default for a pre-existing database. If no value for the 
property is stored in the database, that is identical to a stored value 
of "derby.security.basic=false". This gives you the wide-open security 
behavior of the 10.x series of releases: none of the security features 
are enabled by default and you have to configure each security feature 
individually.

This is what I had in mind. However, more flexible schemes are possible. 
I haven't given these much thought. Options (B) and (C) below have the 
advantage that machinery will be in place if we need to add higher 
security levels later on.

----------------------------

B) Security level - A more complicated scheme would be a property which 
would allow you to dial the security level up and down. As with the 
on/off switch, the property would be stored in the database at creation 
time. I haven't thought about the implications of changing it afterward.

    derby.security.level=

    Can be set to one of the following:

    none            This is the wide-open security behavior of the 10.x 
series.
    basic            This enables the security features at the end of 
this message.
    encrypted     This is basic plus encryption.

If no value for the property is stored in the database, that is 
identical to a stored value of "derby.security.level=none".

C) Release level - A more complicated scheme would be a property which 
would allow you to peg the security level to what was considered best 
practices when a particular release was published. E.g.:

    derby.security.version=10.11.4.3


-----------------------------

Here is the initial set of security features which would be enabled in 
11.x if the master knob were set:

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.


Mime
View raw message