db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2196) Run standalone network server with security manager by default
Date Thu, 08 Feb 2007 16:24:08 GMT

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

Daniel John Debrunner commented on DERBY-2196:

The issue is that there would be a security hole with huge consequences.
A cracker might see the Derby code and think if I can set derby.derby.jar to an empty string
for a remote server then I will silently have a pretty full set of abilities to maniplate
that machine. And the person running the server would probably never notice. That's a pretty
attractive target for a cracker to go after. Then the cracker would figure out how to do it,
and maybe it's as simple as modifying the application's startup script for the server, it
doesn't have to mean they can set Java system properties in a running JVM. And we know through
viruses etc. that such attacks do occur. I'm sure the core vunerability at any successful
attack looks vanishingly small by itself.

Security analysis is much easier is something is impossible, rather than possible, e.g. in
this case codebase can not be set to an empty string if using ${derby.install.url}/derby.jar.

Thanks for switching to a single property. Since this is an internal property I'm wondering
if a different namespace to derby.* would be more secure, e.g. ${org.apache.derby.install.url}.
 This might ease security analysis as we could expect that application code might have permission
to set derby.* (again removing possibilities) but since this will only be used for a fixed
policy file it might not help. Probably sticking with derby.install.url is good for now and
a separate issue could be raised for switching the internal name if required.

> Run standalone network server with security manager by default
> --------------------------------------------------------------
>                 Key: DERBY-2196
>                 URL: https://issues.apache.org/jira/browse/DERBY-2196
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Server, Security
>            Reporter: Daniel John Debrunner
>         Assigned To: Rick Hillegas
>         Attachments: derby-2196-01-print-01.diff, derby-2196-01-print-02.diff, derby-2196-01-print-03.diff,
secureServer.html, secureServer.html, secureServer.html, secureServer.html, secureServer.html,
> From an e-mail discussion:
> ... Derby should match the security  provided by typical client server systems such as
DB2, Oracle, etc. I 
> think in this case system/database owners are trusting the database 
> system to ensure that their system cannot be attacked. So maybe if Derby 
> is booted as a standalone server with no security manager involved, it 
> should install one with a default security policy. Thus allowing Derby 
> to use Java security manager to manage system privileges but not 
> requiring everyone to become familiar with them.
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200612.mbox/%3c4582FE67.7040308@apache.org%3e
> I imagine such a policy would allow any access to databases under derby.system.home and/or
> By standalone I mean the network server was started though the main() method (command

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

View raw message