db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Digulla (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3083) Network server demands a file called "derbynet.jar" in classpath
Date Tue, 20 Nov 2007 09:52:43 GMT

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

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

> To my thinking increasing a security hole in any way is not a good direction to go in.

That would mean it is okay for users, who have to rename the JARs, to have no security at
all.

Your whole argument goes like this: Someone hacks the VM, intercepts the bytecode executor
or the JIT, injects malicious code in the right place (after the system properties from the
command line have been overwritten by NetworkServerControl.installSecurityManager() and before
they are used to install the security policy) and thus takes over the network manager. A possible
scenario, I admit. Anyone here who believes this will ever happen?

If I gain access to the VM, it would be much more simple to use the debug API to replace the
class implementing the SecurityManager or to patch the JARs and restart the service.

So ... yes, Ricks approach widens the security window but I fail to see it creating a wider
attack vector than what we already have. If you have access to the VM, then you can whack
this security scheme to death but my understanding of the whole secuity manager in the Derby
context is to make sure it is not possible to inject malicious code from the network side.
At the time when the SM is installed, Derby doesn't accept connections, so there is no attack
vector at this time.

After that, the SM is installed and malicious code from outside is confined within the limits
of the SM.

If someone has access to the machine, no SM in the world can prevent them to play with the
JARs, the classpath or the VM. That is host security and completely outside the scope of Derby.

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


Mime
View raw message