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 16:05:38 GMT
On 9/20/11 8:41 AM, Mamta Satoor wrote:
> Hi Rick,
>
> Does this mean that a pre-existing database will always be run with
> the knob off after hard-upgrade to 11.x release(or whatever the
> release number which will have the security features)?
Hi Mamta,

I think that we will minimize upgrade problems if the knob defaults to 
"false" for legacy databases. That means that those databases won't 
enjoy the convenience of turning on (1-6) with one knob.
>   Or will "B)
> Security level" give users the option to use security features after
> hard-upgrade?
I think that "derby.security.basic=false" (for option A) and 
"derby.security.level=none" (for option B) simply mean that the database 
follows the security behavior of the 10.x releases. Security features 
can still be enabled and disabled as in 10.x--you just don't have a 
master knob which turns them on.

Thanks,
-Rick
> thanks,
> Mamta
>
> On Tue, Sep 20, 2011 at 8:09 AM, Rick Hillegas<rick.hillegas@oracle.com>  wrote:
>> 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