Derby
  1. Derby
  2. DERBY-5636

Improve the overview of Derby's security mechanisms

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: 10.9.1.0
    • Component/s: Documentation
    • Labels:
      None
    • Bug behavior facts:
      Security

      Description

      The documentation on Derby's security mechanisms is scattered across several manuals. This makes it hard for developers to figure out which security mechanisms are relevant for a given application. Here are 3 places where security documentation appears:

      1) In the Developer's Guide section titled "Derby and security"

      2) In the Admin Guide section titled "Derby Network Server advanced topics"

      3) In the Reference Manual section titled "Derby properties" as well as the syntax sections on GRANT, REVOKE, CREATE/DROP ROLE, and CREATE FUNCTION/PROCEDURE.

      It would be good to add a section which points the developer at all of this material. It might be sufficient to rewrite the top level "Derby and security" page of the Developer's Guide. The following white paper may help organize our thoughts about this: http://www.oracle.com/technetwork/java/javadb/securitywhitepaper10-159253.pdf

      1. DERBY-5636.diff
        9 kB
        Kim Haase
      2. DERBY-5636.stat
        0.1 kB
        Kim Haase
      3. DERBY-5636.zip
        7 kB
        Kim Haase
      4. DERBY-5636-2.diff
        8 kB
        Kim Haase
      5. DERBY-5636-2.stat
        0.3 kB
        Kim Haase
      6. DERBY-5636-2.zip
        16 kB
        Kim Haase
      7. DERBY-5636-3.diff
        8 kB
        Kim Haase
      8. DERBY-5636-3.zip
        15 kB
        Kim Haase

        Activity

        Hide
        Kim Haase added a comment -

        Changes have appeared in Latest Alpha Manuals.

        Show
        Kim Haase added a comment - Changes have appeared in Latest Alpha Manuals.
        Hide
        Kim Haase added a comment -

        Thanks for all the help, Rick!

        Still no commit email, but: I committed patch DERBY-5636-3.diff to documentation trunk at revision 1305845.

        Show
        Kim Haase added a comment - Thanks for all the help, Rick! Still no commit email, but: I committed patch DERBY-5636 -3.diff to documentation trunk at revision 1305845.
        Hide
        Rick Hillegas added a comment -

        Thanks, Kim. The latest patch looks great. +1

        Show
        Rick Hillegas added a comment - Thanks, Kim. The latest patch looks great. +1
        Hide
        Kim Haase added a comment -

        Thanks, Rick – I was wondering about that bullet list. Attaching DERBY-5636-3.diff and DERBY-5636-3.zip, with that change. Hope that does it.

        Show
        Kim Haase added a comment - Thanks, Rick – I was wondering about that bullet list. Attaching DERBY-5636 -3.diff and DERBY-5636 -3.zip, with that change. Hope that does it.
        Hide
        Rick Hillegas added a comment -

        Thanks for these changes, Kim. They look good. One comment:

        cdevcsecure10983:

        I would remove everything from "Other security holes" onward. I think that those vulnerabilities are just examples of how you could go about attacking Derby once you got your hands on a database. There are lots of ways to drill into a stolen database, and these examples don't strike me as worth special mention.

        Thanks,
        -Rick

        Show
        Rick Hillegas added a comment - Thanks for these changes, Kim. They look good. One comment: cdevcsecure10983: I would remove everything from "Other security holes" onward. I think that those vulnerabilities are just examples of how you could go about attacking Derby once you got your hands on a database. There are lots of ways to drill into a stolen database, and these examples don't strike me as worth special mention. Thanks, -Rick
        Hide
        Kim Haase added a comment -

        I'm attaching DERBY-5636-2.diff, DERBY-5636-2.stat, and DERBY-5636-2.zip, this time with the following changes:

        M src/devguide/cdevcbabejdfj.dita
        M src/devguide/cdevcsecure10983.dita
        M src/devguide/cdevbabejgjd.dita
        M src/devguide/cdevcsecure871387.dita
        M src/devguide/rdevcsecure871422.dita
        M src/devguide/rdevcsecure871406.dita
        M src/devguide/rdevcsecure871439.dita

        The substantive changes are to "Notes on the Derby security features", cdevcsecure10983.dita. The other fixes clean up obsolete language and links in the security policy topics.

        Any and all fixes to these are welcome. Thanks again, Rick.

        Show
        Kim Haase added a comment - I'm attaching DERBY-5636 -2.diff, DERBY-5636 -2.stat, and DERBY-5636 -2.zip, this time with the following changes: M src/devguide/cdevcbabejdfj.dita M src/devguide/cdevcsecure10983.dita M src/devguide/cdevbabejgjd.dita M src/devguide/cdevcsecure871387.dita M src/devguide/rdevcsecure871422.dita M src/devguide/rdevcsecure871406.dita M src/devguide/rdevcsecure871439.dita The substantive changes are to "Notes on the Derby security features", cdevcsecure10983.dita. The other fixes clean up obsolete language and links in the security policy topics. Any and all fixes to these are welcome. Thanks again, Rick.
        Hide
        Kim Haase added a comment -

        This is odd – I committed the patch 4+ hours ago, but the commit message has not shown up yet. I got an error when I did an svn update recently, but not any more.

        Anyhow, I committed patch DERBY-5636.diff to documentation trunk at revision 1305386. It's in my log ...

        I will move on to making the fixes to "Notes on the Derby security features" and will file a second patch. Thanks very much for the suggestions, Rick.

        Show
        Kim Haase added a comment - This is odd – I committed the patch 4+ hours ago, but the commit message has not shown up yet. I got an error when I did an svn update recently, but not any more. Anyhow, I committed patch DERBY-5636 .diff to documentation trunk at revision 1305386. It's in my log ... I will move on to making the fixes to "Notes on the Derby security features" and will file a second patch. Thanks very much for the suggestions, Rick.
        Hide
        Rick Hillegas added a comment -

        Hi Kim,

        Yes, I think that rewriting that section in order to punch up those points would be good. If someone knows what "trolling for objects" means, then we can clarify that point too. Thanks.

        Show
        Rick Hillegas added a comment - Hi Kim, Yes, I think that rewriting that section in order to punch up those points would be good. If someone knows what "trolling for objects" means, then we can clarify that point too. Thanks.
        Hide
        Kim Haase added a comment -

        Thanks, Rick – I will commit the patch. Do you think it would be a good idea to rewrite the "Notes on the Derby security features" to make the two points you describe in your comment?

        Show
        Kim Haase added a comment - Thanks, Rick – I will commit the patch. Do you think it would be a good idea to rewrite the "Notes on the Derby security features" to make the two points you describe in your comment?
        Hide
        Rick Hillegas added a comment -

        Hi Kim,

        The changes so far look good. +1 to commit them.

        I'm not sure about why we have the section titled "Notes on the Derby security features". Its purpose might be to alert users to vulnerabilities which Derby does not address and which the application is responsible for addressing. I don't know what "trolling for objects" means. The vulnerabilities I understand seem to boil down to these problems:

        1) If someone gets physical access to your database (e.g., they are able to copy it onto their own disk), then they can subvert all other security mechanisms given enough time. Your best Derby defense against this exploit is to encrypt the data. However, if the encryption can be broken, then the data is vulnerable. I don't know what the application can do about this problem other than "try not to let this happen."

        2) There are no authorization checks for system-wide operations. Anyone who can authenticate at the system level enjoys god-like powers to shutdown the engine and restore databases. Your best Derby defense here is to limit the number of users who can authenticate at the system level. This is easy to do with NATIVE authentication: just put 1 superuser in the system-wide credentials db and store the database-specific users in their respective databases. You can do this with LDAP by using different LDAP servers for system-wide and database-specific authentication.

        Thanks,
        -Rick

        Show
        Rick Hillegas added a comment - Hi Kim, The changes so far look good. +1 to commit them. I'm not sure about why we have the section titled "Notes on the Derby security features". Its purpose might be to alert users to vulnerabilities which Derby does not address and which the application is responsible for addressing. I don't know what "trolling for objects" means. The vulnerabilities I understand seem to boil down to these problems: 1) If someone gets physical access to your database (e.g., they are able to copy it onto their own disk), then they can subvert all other security mechanisms given enough time. Your best Derby defense against this exploit is to encrypt the data. However, if the encryption can be broken, then the data is vulnerable. I don't know what the application can do about this problem other than "try not to let this happen." 2) There are no authorization checks for system-wide operations. Anyone who can authenticate at the system level enjoys god-like powers to shutdown the engine and restore databases. Your best Derby defense here is to limit the number of users who can authenticate at the system level. This is easy to do with NATIVE authentication: just put 1 superuser in the system-wide credentials db and store the database-specific users in their respective databases. You can do this with LDAP by using different LDAP servers for system-wide and database-specific authentication. Thanks, -Rick
        Hide
        Kim Haase added a comment -

        Attaching DERBY-5636.diff, DERBY-5636.stat, and DERBY-5636.zip, with changes to just a couple of files (so far):

        M src/devguide/cdevcsecuree.dita
        M src/devguide/cdevcsecure90988.dita

        I added links and new information to "Derby and security". More suggestions are welcome.

        I found some old crufty stuff in "Signed jar files" (cdevcsecure90988.dita) when verifying the link to it – mentions of "Java 2", for example. There is more cleanup to be done in this area if we wanted to go down that road – the section "Running Derby under a security manager" has more elderly terminology and links.

        I am also wondering if the topic "Notes on the Derby security features" needs any changes at this point.

        Show
        Kim Haase added a comment - Attaching DERBY-5636 .diff, DERBY-5636 .stat, and DERBY-5636 .zip, with changes to just a couple of files (so far): M src/devguide/cdevcsecuree.dita M src/devguide/cdevcsecure90988.dita I added links and new information to "Derby and security". More suggestions are welcome. I found some old crufty stuff in "Signed jar files" (cdevcsecure90988.dita) when verifying the link to it – mentions of "Java 2", for example. There is more cleanup to be done in this area if we wanted to go down that road – the section "Running Derby under a security manager" has more elderly terminology and links. I am also wondering if the topic "Notes on the Derby security features" needs any changes at this point.
        Hide
        Kim Haase added a comment -

        The "Derby and security" main topic should clarify the authentication/authorization distinction as described by Rick under DERBY-5522, or should at a minimum point to other topics that make this clear:

        1) Authentication determines whether you are a legal user. It establishes your identity.

        2) Authorization determines what operations can be performed by you, that is, by your Derby identity.

        So far, so good. Those are just generic definitions of authentication and authorization which hold true for lots of software, not just Derby. Now for the tricky bit, which is specific to Derby:

        Derby understands two kinds of identity:

        A) System-wide identity. Currently, any legal system-wide identity enjoys authorization to perform the following operations:

        i) Create databases.

        ii) Restore databases.

        iii) Shutdown the Derby engine.

        B) Database-specific identity. If you are a legal identity in a specific-database, then you may enjoy the following rights:

        i) You can connect to that database--provided that coarse-grained connection authorization has not been set to noAccess.

        ii) You can shutdown that database, encrypt it, and upgrade it--provided that you are the database owner.

        iii) You can create your own SQL objects and write data to your own tables--provided that your coarse-grained connection authorization has not be set to readOnlyAccess.

        iv) You can access other SQL objects--provided that the owners have granted you fine-grained SQL access to those objects and provided you have not been limited by coarse-grained readOnlyAccess.

        Show
        Kim Haase added a comment - The "Derby and security" main topic should clarify the authentication/authorization distinction as described by Rick under DERBY-5522 , or should at a minimum point to other topics that make this clear: 1) Authentication determines whether you are a legal user. It establishes your identity. 2) Authorization determines what operations can be performed by you, that is, by your Derby identity. So far, so good. Those are just generic definitions of authentication and authorization which hold true for lots of software, not just Derby. Now for the tricky bit, which is specific to Derby: Derby understands two kinds of identity: A) System-wide identity. Currently, any legal system-wide identity enjoys authorization to perform the following operations: i) Create databases. ii) Restore databases. iii) Shutdown the Derby engine. B) Database-specific identity. If you are a legal identity in a specific-database, then you may enjoy the following rights: i) You can connect to that database--provided that coarse-grained connection authorization has not been set to noAccess. ii) You can shutdown that database, encrypt it, and upgrade it--provided that you are the database owner. iii) You can create your own SQL objects and write data to your own tables--provided that your coarse-grained connection authorization has not be set to readOnlyAccess. iv) You can access other SQL objects--provided that the owners have granted you fine-grained SQL access to those objects and provided you have not been limited by coarse-grained readOnlyAccess.

          People

          • Assignee:
            Kim Haase
            Reporter:
            Rick Hillegas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development