db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-866) Derby User Management Enhancements
Date Tue, 22 Nov 2011 21:06:40 GMT

    [ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155433#comment-13155433

Rick Hillegas commented on DERBY-866:

Here is my next tranche of thoughts about building a more secure out-of-the-box authentication
mechanism for Derby. I address two topics:

1) Setting a reasonable goal.

2) Handling system-wide users.

------------- Setting a Reasonable Goal -------------------

Francois raised the point that if someone can read or write your database directories, then
you may have already lost the security battle. If someone can read your database directories,
then they can copy the database to a workbench area and crack it at their leisure. If someone
can write to the database directories, then they can alter your database; they might even
escape detection via an exploit like the one described by DERBY-5510.

If the attacker can connect to a Derby engine which reads directories holding your database,
then the attacker can copy the database to a workbench area by exploiting the vulnerability
described by DERBY-2470. By using the RESTORE functionality, the attacker does not even need
valid credentials to do this.

Encryption may help protect you from these attacks. However, as Francois points out, once
the attacker has a physical copy of your database, cracking it may only be a matter of time.
Derby encryption may be particularly vulnerable because system conglomerates keep their original
names and begin with known sequences of bytes. It is possible that encrypted file systems
may give you a bit more protection.

For these reasons, I do not expect this JIRA to address the following non-goals:

A) We are not trying to protect Derby databases on mobile devices like laptops and phones.

B) We are not trying to protect Derby databases on removable media like USB sticks.

However, I still think that we can boost the security of databases which live in physically
secure locations such as servers inside protected machine rooms. This includes databases embedded
inside user-written server applications and databases running inside Derby's own server framework.

------------- Handling System-wide Users -------------------

This JIRA focuses on the problem of database-specific users. However, we need to give some
thought to the problem of system-wide users. These users appear in the following situations:

i) The credentials of Derby network administrators. Here there is no distinguished database
to which we can tie the credentials.

ii) The credentials needed to create a database. Since the database doesn't exist yet, we
can't tie credentials to it.

I am tempted to add the following case too:

iii) The credentials needed to restore a database from a backup. We might want to address
this problem by authenticating the user in a read-only connection to the backup BEFORE restoring
from it. On the other hand, previous discussions related to DERBY-2109 and DERBY-2470 have
compared this use-case to database creation. If we want to treat this case like database creation,
then we may want to treat the credentials like case (ii) above.

Here are some options for managing system-wide credentials:

I) Via system-wide properties, stated either on the JVM boot command or in a properties file.
Maybe we could reuse the existing BUILTIN user/password properties for this purpose. I do
not recommend this solution because it seems vulnerable to being spied on.

II) Via some encrypted file managed by Derby. This would require building system-wide machinery
for changing credentials and for disaster recovery. One variation of this approach might be
a master database which just holds system-wide credentials.

III) Via some application-supplied authenticator. This pushes the problem into the application
and seems to defeat the intent of this JIRA.

Maybe you can think of some other approaches. As you can tell, I am not thrilled by any of
the solutions above.

Perhaps we can finesse these problems and not create a concept of system-wide users:

i') We already have a solution to (i): The server administration credentials are invented
at server boot time. In a properly configured server (forget NetServlet), the server can only
be booted by someone who has passed other, enterprise-supplied authentication hurdles.

ii') Do not allow arbitrary users to write their own Derby connection URLs. The trick here
is for the embedding application to not provide a means by which users can specify arbitrary
connection URLs. That is, educate users to treat URL injection like SQL injection.

iii') We could tackle this as a case similar to (ii'). Or we could first authenticate in a
read-only connection to the backup, as noted above.

I would appreciate your additional thoughts about these topics. Thanks.

> Derby User Management Enhancements
> ----------------------------------
>                 Key: DERBY-866
>                 URL: https://issues.apache.org/jira/browse/DERBY-866
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>    Affects Versions:
>            Reporter: Francois Orsini
>         Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html
> Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached
to the JIRA).
> Abstract:
> This feature aims at improving the way BUILT-IN users are managed in Derby by providing
a more intuitive and familiar DDL interface. Currently (in, Built-In users can be
defined at the system and/or database level. Users created at the system level can be defined
via JVM or/and Derby system properties in the derby.properties file. Built-in users created
at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY)
which sets a database property.
> Defining a user at the system level is very convenient and practical during the development
phase (EOD) of an application - However, the user's password is not encrypted and consequently
appears in clear in the derby.properties file. Hence, for an application going into production,
whether it is embedded or not, it is preferable to create users at the database level where
the password is encrypted.
> There is no real ANSI SQL standard for managing users in SQL but by providing a more
intuitive and known interface, it will ease Built-In User management at the database level
as well as Derby's adoption.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message