db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <stan.bradb...@gmail.com>
Subject Re: making Derby secure by default
Date Sun, 18 Sep 2011 16:57:29 GMT
I strongly recommend that this topic be posted to derby-user for comment.
Afterall it is their applications that will be impacted should the secure by
default be implemented.  For my part I agree with Kathey, leave the default
as the old behavior (especially for embedded) and strongly recommend that
groups that do not already secure derby at the application level set
SECURITY = ON (or whatever the flag may be).  My experience is that Derby is
not broken in this regard so it need not be fixed.  However, making it very
easy to turn on all the security features is an excellent ease of use
enhancement and I support this.  Had this thread been taken to derby-user
you I would have responded earlier.

Regarding Derby embedded.  The 100+ product release teams I work with that
bundle embedded Derby do so because of it's ease of use.  The embedded Derby
system is protected by the application level security that protects the
larger system.  The teams see elegance in this simplicity, it sets Derby
apart from most other systems.  Many teams have used Derby since version
10.3 and greatly appreciate the simplicity of moving from one version to
another.  It won't be the end of the world should these teams have to add an
additional property to maintain original behavior but some will ask why the
old behavior was not the default. Without taking this to the derby-user
group can the development community say they did due diligence in making
this decision?

From: Kathey Marsden <kmarsdenderby@sbcglobal.net>
To: derby-dev@db.apache.org
Date: Tue, 13 Sep 2011 15:29:30 -0700
Subject: Re: making Derby secure by default
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.

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

o DERBY-866: Derby User Management Enhancements

o DERBY-2133: Detect tampering of installed jar files in an encrypted

o DERBY-2206/DERBY-2250/DERBY-22
> 53/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