db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From davi...@sonic.net
Subject Re: plugging more security holes in Derby
Date Wed, 29 Nov 2006 23:58:40 GMT
I'm sure I'm missing something, but all your proposals sound pretty good
to me on the face of it.

David

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



Mime
View raw message