Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Wed, 29 Nov 2006 12:47:16 -0800
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: plugging more security holes in Derby
In-reply-to: <455DF530.1060004@sun.com>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <456DF1D4.8060106@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <455DF530.1060004@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060828)

Thanks to Dan and Dag, I believe that Derby system privileges are 
beginning to look much simpler. I would like to continue the discussion 
about how we can plug more security holes in our client/server 
configuration. So far we have discussed the following:

1) System-wide privileges (shutdown system, shutdown all databases, 
create databases).

2) Database-specific privileges (shutdown, encrypt, upgrade, create 
plugins).

I would like to add another topic to the discussion:

3) Knobs. What kind of knobs do we need to control default behavior and 
make upgrade smooth?

Here then are some more thoughts:

------------ 1) System-wide Privileges ----------------------

The alternatives so far:

1a) GRANT/REVOKE in a master database
1b) A user-implementable api modelled on 
org.apache.derby.authentication.UserAuthenticator
1c) Java permissions

Some comparisons:

(1a)
+ Familiar api
- Non-standard extensions to that api
- Heavyweight

(1b)
+ Flexible
+ Easy to extend
+ Master database (something like (1a)) could be added as a special 
implementation
+ Modelled on an existing Derby api

(1c)
+ Standard mechanism
+ Simple administration
+ Easy to extend
- Requires that the whole VM runs under a SecurityManager

I don't feel that it would be too onerous to require a SecurityManager 
for the whole VM. I prefer (1c) over the other approaches because it is 
a standard mechanism.

------------ 2) Database-specific Privileges ----------------------

The alternatives so far:

2a) GRANT/REVOKE extensions
2b) Limiting privileges to the database owner

Some comparisons:

(2a)
+ Familiar mechanism
- Heavyweight overkill for most of the privileges

(2b)
+ Simple
+ Adequate for most of the privileges
- Perhaps overly restrictive for Plugin  privilege
- How to migrate database ownership if DBA kicked upstairs to be CTO

I prefer (2b) because it is simple. I think we could address its issues 
as follows:

i) Treat the Plugin power as a system-wide privilege rather than a 
database-specific privilege. Manage Plugin power using Java permissions 
per (1c).

ii) We could add a warning paragraph to the security section of the 
Developer's Guide. This paragraph would advise client/server users to 
create special dba accounts for their databases so that they can migrate 
database powers to a new dba when the old dba moves on to new 
responsibilities. If this situation turns out to be a problem, a 
follow-on release could introduce some mechanism for migrating the 
ownership of databases.

------------ 3) Knobs ----------------------

In 10.2 we introduced a new knob, a property called 
/derby.database.sqlAuthorization/. Its default setting (false) preserves 
legacy Derby behavior, i.e., permissions are not GRANTed and existing 
client/server applications continue to function in the old, insecure way 
that is appropriate for embedded applications. Setting this property to 
true enables permissions checking.

When we introduce system-wide and database-specific privileges we will 
need at least one more knob. This additional knob will control whether 
these privileges are checked or whether legacy applications continue to 
behave as they did in 10.2. Let us suppose this is another property. 
Here are two ways to handle this knob:

3a) It could be boolean, that is, take true/false values just like 
/derby.database.sqlAuthorization./

3b) Alternatively, it could be an integer, specifying the 
privilege-checking level of the Derby engine.

Approach (3b) seems more flexible to me. It would allow us to add more 
system/database privileges in future releases. Let's call this knob 
/derby.system.privLevel/. It could behave as follows:

derby.system.privLevel unspecified (Default behavior. We don't check for 
database or system privileges.)
derby.system.privLevel=10.2 (Default behavior above.)
derby.system.privLevel=10.3 (We check for the database and system 
privileges introduced in 10.3.)
derby.system.privLevel=10.4 (We check for the database and system 
privileges handled by the previous release as well as any new database 
and system privileges introduced in 10.4.)

Please let me know what you think about this proposal and whether you 
have other ideas about how to manage the upgrading of legacy 
applications to 10.3.

Thanks,
-Rick