db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject making Derby secure by default
Date Tue, 13 Sep 2011 17:57:49 GMT
Derby (originally Cloudscape) grew up as an embedded database with 
little need to protect users from themselves. Over time, many opt-in 
security features were added to Derby. For backward compatibility 
reasons, these features default to being turned off. Consequently, Derby 
is not a secure piece of software out of the box. In addition, it is 
easy to forget to turn on all relevant opt-in security mechanisms.

Fifteen years after initial development started on this codeline, Derby 
has survived into a world which is hyper-sensitive about computer 
security. With alarming regularity we read how compromised personal data 
leaves millions of people exposed to identity theft and other abuses. 
Often these breaches result from chaining together the vulnerabilities 
in many products. I am worried that one day Derby will appear in the 
news as one of the products in a high-profile vulnerability chain.

I would like to discuss what it would take to make Derby secure by 
default. Hopefully the community can broadly support this goal. It seems 
to me that we need to explore at least two important topics:

1) What additional work needs to be done to make Derby secure by default?

2) How do we reconcile these behavioral changes with our backward 
compatibility guarantees?

One approach to topic (2) would be the following:

2a) Finish up the items in (1) as opt-in features like our other 
security mechanisms. We could add these features over the next (couple) 
10.x release(s).

2b) When we have finished that list, produce an 11.0 release which is 
not backward compatible. In 11.0, most security mechanisms would default 
to being on and users would have to explicitly opt-out of security features.

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.

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 

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 

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.


View raw message