Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <25079627.1195637923061.JavaMail.jira@brutus>
Date: Wed, 21 Nov 2007 01:38:43 -0800 (PST)
From: "Aaron Digulla (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3083) Network server demands a file called
 "derbynet.jar" in classpath
In-Reply-To: <17082838.1190192623682.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544392 ] 

Aaron Digulla commented on DERBY-3083:
--------------------------------------

> No, my argument is that there is a vulnerability, thus it is subject to be being exploited.

Okay, let me see if we're on the same track here: A Security Manager will do this: It will enforce allowed operations on specific JARs on the classpath. The JARs are not signed and not protected in any way other than their name and path.

So Daniel's arguments boils down to this: "I enhance security by enforcing the JAR to have a certain name/path". I do not believe this is true. As long as I can add malicious code to the JAR without the SM noticing, enforcing the name will not give additional protection. Therefore, enforcing a specific name will only add a false sense of security which isn't really there. This is even more dangerous than having an unknown vulnerability since people will believe they are safe when they are not.

To be as safe as we can possibly be, I suggest that you use Class.getResource() on specific classes which should be on the classpath and strip the package and class from the resulting URL. This will be as safe as the static JAR names (as to my argument above) and it will work for both the case that the JARs have been renamed and that they have been collected in an ueberjar.

For the same reasons, storing these URLs in the system properties (or any global variable) is okay too, because this cannot be exploited from a remote attacker and the SM doesn't give any protection against a local attacker anyway. As long as users use the supplied code, they will be perfectly safe as long as no one can modify the classpath when the server is started. If they embed the code in a larger app, they have to think about security themselves; we aren't able to forsee what they might do and therefore, we can't make their code secure for them at this time.

> Network server demands a file called "derbynet.jar" in classpath
> ----------------------------------------------------------------
>
>                 Key: DERBY-3083
>                 URL: https://issues.apache.org/jira/browse/DERBY-3083
>             Project: Derby
>          Issue Type: Bug
>          Components: Tools
>    Affects Versions: 10.3.1.4
>            Reporter: Aaron Digulla
>         Attachments: derby-3083-01-requireDerbynet-aa.diff, derby-3083-01-requireDerbynet-ab.diff, derby-716-10-datatypesCollation-aa.diff
>
>
> The network server will not start if the derbynet jar is added under a different name than "derbynet.jar" to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to "derbynet-10.3.1.4.jar".
> This did work with 10.2.2.0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.