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.
