db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: Derby secure by default
Date Tue, 20 Sep 2011 15:41:23 GMT
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)? Or will "B)
Security level" give users the option to use security features after
hard-upgrade?

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