Thanks, Kathey. Some comments inline...
On 9/16/11 9:06 AM, Kathey Marsden wrote:
On 9/16/2011 5:59 AM, Rick Hillegas wrote:
I believe the benefits of a secure-by-default product are important
enough to justify a backwardly incompatible release and therefore to
bump the major release id from 10 to 11. I believe that Derby's
current security story is unsustainable.
I believe an ultimate switch and bump to 11 might be doable with the
global property to revert to to the prior behavior but I don't
entirely understand what the new default will require users to do.
I'd like to understand that clearly
More discussion is required, but here are my initial thoughts for how
Derby would behave when secureByDefault=true:
The following defenses would be in place in both embedded and
client/server scenarios:
E1) We would supply a default authentication scheme for use when no
other scheme is specified. The details of this can be discussed further
on DERBY-866.
E2) Authentication and authorization would be turned on. If using the
default authentication scheme, we would store the credentials used to
create the database; the dbo would be responsible for creating
additional users.
E3) We would use the tighter file permissions introduced by DERBY-5363.
E4) We would enforce the complete SQL security model for Java routines
(see DERBY-2206/DERBY-2250/DERBY-2253/DERBY-2252).
E5) The user name PUBLIC would not be allowed.
I don't know what to do about database encryption. For performance
reasons, we might want to leave it off. Alternatively, we might consider
default encryption of new databases using a salted version of the DBO's
password.
The following additional defenses would be in place in client/server
scenarios:
CS1) The VM owner would have to specify credentials in order to boot the
server.
CS2) Those credentials would be required in order to shutdown the
server, shutdown the engine, turn server-side tracing on/off, and in
general use any of the public functions of NetworkServerControl/NetServlet.
CS3) SSL/TLS would be turned on. Unless overridden, certificate/key
stores would be expected/created at some default location.
CS4) Some mechanism would control create/restore database powers across
the network. Discussion needed.
and have the switch with the reversed default in place for a while for
users to work with before we flip the switch on the default and bump
the major version. I think it is really important that we are sure
that the needed user actions with the option on are well documented
and proven in the field before the default is changed.
Agreed.
If the whole community can't move to a secure-by-default product, I
am worried that Derby development may fork. Those of us who are
interested in a secure-by-default configuration will put our effort
behind that profile and those who are interested in the old
configuration will focus on the current profile. It may be possible
to limit the fork to personal environments and automated tests, but I
confess, I don't understand how this would play out. Before launching
into that discussion, I would like to ask if the community could
support a secure-by-default 11.0 trunk sometime after 10.9 in the
interests of avoiding a development fork.
I certainly hope a fork won't be necessary. Worst case there could be
an alternate build with the default switched if some people what to
distribute the jars with the option flipped if some are more eager to
do so.
We should be able to control this with a build-time switch. If we
released both versions, then we would want to track the difference in
JIRA somehow.
Thanks,
-Rick
Kathey
