Notes on the Derby Security Features

Because Derby does not support traditional grant and revoke features, the security model has some basic limitations. For both embedded and client/server systems, it assumes that users are trusted. You must trust your full-access users not to perform undesirable actions. You lock out non full-access users with database properties, which are stored in the database (and in an encrypted database these properties are also encrypted). Note, however, for a distributed/embedded system that a sophisticated user with the database encryption key might be able to physically change those properties in the database files.

In addition, in the Derby system, it is not necessary to have a specific connection (or permission to access a particular database) to shut down the system. Any authenticated user can shut down the system.

Other security holes to think about are:

• JVM subversion, running the application under a home-grown JVM.
• trolling for objects
• class substitution, locating a class that has access to sensitive data and replacing it with one that passes on information