[ 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. EXPERIMENT 1: 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. EXPERIMENT 2 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. EXPERIMENT 3 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 privilege. 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. CONCLUSIONS 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: 10.3.0.0 > Reporter: Rick Hillegas > Fix For: 10.3.0.0 > > 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
