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
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
