db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dag.wan...@oracle.com (Dag H. Wanvik)
Subject Re: making Derby secure by default
Date Wed, 14 Sep 2011 12:06:54 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> On 9/13/2011 10:57 AM, Rick Hillegas wrote:
>> 2c) To ease the migration to 11.0, it might be possible to add a
>> single knob which lets an application opt-out of the 11.0 defaults
>> and instead run with the 10.x security defaults.
> I think a single knob is a good idea but the default should be off to
> preserve backward compatibility and the zero admin aspects of the
> product at this time.   Warnings and education can be used to coax
> users to transition and then maybe after multiple releases with the
> knob the default could be changed and the major version changed if
> there is enough experience with the super knob to understand all the
> steps that have to be taken in addition to turning it on.

If so, there is no need for a version 11.0 IMHO, at least not before
such as time as we turn the default of the super knob.  The whole point
of moving to an 11 series is that it would allow for changed defaults at
the outset, as I see it (new major release should be a red flag). I am
not sure if it is entirely reasonable to expect a new release (11.0) to
work out-of-box for existing deployments.


>> Concerning topic (1), it seems to me that the biggest hurdle to
>> building a secure-by-default Derby is our lack of user
>> management. The BUILTIN security mechanism has many defects which
>> make it unsuitable for use in production. Here is my short list of
>> security features which I think that we should build:
>> o DERBY-866: Derby User Management Enhancements
>> o DERBY-2133: Detect tampering of installed jar files in an
>> encrypted database
>> o DERBY-2206/DERBY-2250/DERBY-2253/DERBY-2252: Provide complete
>> security model for Java routines
>> o DERBY-2363: Add initial handshake on connection setup to determine
>> server's required ssl support level and avoid client side attribute
>> settings.
>> o DERBY-2436: SYSCS_IMPORT_TABLE can be used to read derby files
>> o DERBY-2470: No authentication required to restore a backup
>> o DERBY-3333: User name corresponding to authentication identifier
>> PUBLIC must be rejected
>> o DERBY-3495/DERBY-3476/DERBY-2109: Enable System Privileges checks
>> o DERBY-4354: Make it possible to grant java permissions to user jar
>> files that are stored in the database
>> o DERBY-5400: Toggling of network tracing should be protected by
>> requiring the user to specify the credentials of the system
>> administrator.
>> o DERBY-5401: The NetServlet should require system administrator
>> credentials in order to perform its operations on a server which
>> requires authentication.
>> I would appreciate your thoughts about this proposal.
>> Thanks,
>> -Rick

View raw message