Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <10721928.1195664460430.JavaMail.jira@brutus>
Date: Wed, 21 Nov 2007 09:01:00 -0800 (PST)
From: "Daniel John Debrunner (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_12544526 ] 

Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------

> So Daniel's arguments boils down to this: "I enhance security by enforcing the JAR to have a certain name/path".
That is my argument yes.

> As long as I can add malicious code to the JAR without the SM noticing, enforcing the name will not give additional protection.
Agreed, it gives no additional protection for that specific situation, I have not claimed it would do. Remember I'm making no assumptions about how a vulnerability is exploited, only that it is there to be exploited. Thus I'm not making assumptions the attacker has access to the a local machine or ability to modify the jars etc.

The policy file that allows an arbitrary name for the code source has the potential for it to be applied to any jar on the file system, a policy file with a specific name portion (such as derby.jar) can only be applied to a limited number of jars on the file system. The policy file in question has some very useful permissions, such as ALL FILES.

> Therefore, enforcing a specific name will only add a false sense of security which isn't really there. 
I've only ever claimed that the specific names reduces a vulnerability.

> storing these URLs in the system properties (or any global variable) is okay too, because this cannot be exploited from a remote attacker
That's an assumption that's hard to prove and one I would not be willing to make when looking at security. Remember the vulnerability exists before the security manager is installed, thus setting system properties is open for any code running in the jvm. Could some JMX agent or debugging agent be active that would allow properties to be set from a remote user (or local user using tcp/ip)?.

> SM doesn't give any protection against a local attacker anyway
One does have to be concerned about local attackers, while a local attacker may have access to the machine (be logged on, able to run processes on the machine), they may not have access to your files, thus there may be incentive for them to exploit vulnerabilities to read/modify your data.

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

These two statements contradict each other, the first says Derby should install a security manager using whatever jar file the code is in, hence giving the impression Derby is making the system secure for them. The second says (correctly) we can't make their code secure for them in this situation.

I'm not sure what Aaron & Rick are really arguing, it's either there is no vulnerability or there is a vulnerability but there's no/little chance of it being exploited.
I think that any security breach is usually made up of a number of  vulnerabilities, not a single point of failure.

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