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