db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2109) System privileges
Date Fri, 15 Dec 2006 18:42:21 GMT
    [ http://issues.apache.org/jira/browse/DERBY-2109?page=comments#action_12458877 ] 
Rick Hillegas commented on DERBY-2109:

I would like to continue the discussion of using doAsPrivileged() vs. doAs(). I ran the following
experiments. For more detail on the code, please refer to the example code in Appendix B of
the attached functional spec.


a) I separated the ShutdownAction into its own class. This is the PrivilegedExceptionAction
which actually calls checkPermission(). I put this class in jarfile jar_A along with the custom
Principal and Permssion classes.

b) I put the entry point class in its own jar file jar_B. This class called the ShutdownAction
using both doAs() and doAsPrivileged()

c) I created a policy file which did the following:

  i) gave jarfile_B the privileges doAs and doAsPrivileged

  ii) gave Shutdown privilege to one distinguished Principal

I observed the following:

I) Calling doAs() failed for all Principals. That is, checkPermission() always reported that
the Shutdown privilege was not granted. This is because code from jarfile_B was at the top
of the stack but jarfile_B did not have Shutdown privilege.

II) Calling doAsPrivileged() functioned correctly: It verified that the distinguished Principal
had the Shutdown privilege and that no-one else did. This is because the call to doAsPrivileged()
passed in a null AccessControlContext. This essentially told the security subsystem to not
bother checking permissions for stack frames above the caller.


This was the same as the previous experiment except that the policy file gave Shutdown privilege
to jarfile_B. I observed the following:

I) doAs() now functioned correctly. The checkPermission() call verified that only the distinguished
Principal had Shutdown privilege.

II) doAsPrivileged() continued to function correctly as in the previous experiment.

This suggested that if we wanted to use doAs(), then we would need to split derby.jar into
2 ProtectionDomains. The outer ProtectionDomain would have to be granted Shutdown privilege.
Code in the inner ProtectionDomain would be run as a PrivilegedExceptionAction under the identity
of the authenticated authorizationId. This inner domain would not be granted a blanket Shutdown
privilege--this is what would allow checkPermission to distinguish the privileges of Principals
who were trusted with Shutdown power.


Here I tried to model an application embedding Derby. This was identical to the previous experiment
with the following additions:

d) A thin entry point (main class) was created and put in its own jarfile_C. All that this
class did was call the entry point in jarfile_B.

e) The policy file was enhanced to grant doAs and doAsPrivileged to jarfile_C.

This experiment behaved like the first experiment. That is:

I) doAs() failed always because the outermost ProtectionDomain, jarfile_C, did not have Shutdown

II) doAsPrivileged() correctly detected that only the distinguished Principal had Shutdown
privilege. This is because doAsPrivileged() threw away all of the outer ProtectionDomains,
including the untrusted jarfile_C domain.


1) Using Java Security to police engineShutdown and createDatabase will mean that additional
privileges (doAs or doAsPrivileged) must be granted not just to derby.jar but to all ProtectionDomains
above Derby on the call stack.

2) Using doAs means that we will have to factor derby.jar into two ProtectionDomains.

> System privileges
> -----------------
>                 Key: DERBY-2109
>                 URL: http://issues.apache.org/jira/browse/DERBY-2109
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security
>    Affects Versions:
>            Reporter: Rick Hillegas
>             Fix For:
>         Attachments: systemPrivs.html
> Add mechanisms for controlling system-level privileges in Derby. See the related email
discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
> The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  secure in a client/server
configuration. I'd like to plug more client/server security holes in 10.3. In particular,
I'd like to focus on  authorization issues which the ANSI spec doesn't address.
> Here are the important issues which came out of the email discussion.
> Missing privileges that are above the level of a single database:
> - Create Database
> - Shutdown all databases
> - Shutdown System
> Missing privileges specific to a particular database:
> - Shutdown that Database
> - Encrypt that database
> - Upgrade database
> - Create (in that Database) Java Plugins (currently  Functions/Procedures, but someday
Aggregates and VTIs)
> Note that 10.2 gave us GRANT/REVOKE control over the following  database-specific issues,
via granting execute privilege to system  procedures:
> Jar Handling
> Backup Routines
> Admin Routines
> Import/Export
> Property Handling
> Check Table
> In addition, since 10.0, the privilege of connecting to a database has been controlled
by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode)
as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message