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<[email protected]> 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.
